vetal: Is this a system with multiple paths to each SAS disk?

It looks suspiciously like you're getting one of several potential paths to the same disk at random each boot?

I have some software that's trying to use both c++11 thread_local and tss(3C), and the thread_local define in threads.h is conflicting with C++ - I don't really understand what "_Thread_local" is, it doesn't appear in any public headers, and should probably be !cplusplus'd?

_Thread_local is the standard C11 keyword for thread local storage. In C++11 it's thread_local, so it does seem like there's a missing guard there.

Oh, and _Thread_local is deprecated in C23

> _Thread_local (until C23) thread_local (since C23) - thread storage duration (since C11)

jclulow: I think you are right)

vetal: The thing that's supposed to happen is that scsi_vhci should sit on top of both of those paths, and you should get one virtual disk with the correct WWN

I'm not sure why that's not happening for you here

(but it seems like a bug!)

What do you see in diskinfo?

are the controllers set for jbod mode and not raid?

vetal: another thing to look at is what value of mpxio_disable is set in the disk controller's .conf file.

mpxio_disable="no" reparents disk devices to the scsi_vhci virtual controller number so the /dev/dsk filename doesn't change when the disk is moved or if a different path is used.

excuse me, mpxio-disable, not mpxio_disable.

andyf: the _Thread_local situation seems tedious at best

but yeah, it seems like someone has to go work out the soup of ifdefs :\

jclulow: my ancient memory says "shouldn't mpxio by default have fixed this?" and seems like a bug sounds right?

jbk: jbod

sommerfeld: Thank you. Will try it.

jclulow: Did you ask about case where cN is changed or case when WWN and device name differs ?