Bryan Kadzban wrote: > The only thing that matters is the order that calls to sd_probe > (assuming SCSI or SATA) occur in, since that's what assigns the index > for each disk. And since neither the kernel as a whole, nor device > discovery in particular, are single threaded, that order can change at > any time, or from run to run... > > The fact that you haven't seen it cause a problem means you're lucky I > think, and haven't lost the race condition. :-)
Can you give me any references about this problem? Or is it just in the kernel code? I just don't see how sda and sdb would be reversed. Of course I understand that an unrestrained set of calls to discover drives would result in a race condition and the order of drives could change, but I'd think I would have seen that at some time over the years. I'll note that on the only RHEL system I have access to, the drive (there is only one in this case) is listed in fstab as sda, not label or id or uuid. On my LFS development system, dmesg says the drives are discovered i the order of scsi 0:0:0:0 (sda), usb 2-4, scsi 0:0:1:0 (sdb), scsi 1:0:0:0 (sdc), scsi 1:0:1:0 (sr0). It's only later that the usb drive, scsi 4:0:0:0, is assigned sdd. Besides, if the devices were swapped, how would udev know which device to symlink to? For example, how would it know to do: /dev/disk/by-id/ata-ST3750330AS_9QK0X0PX -> ../../sdb >> I have 3 SATA disks plugged into ports 1, 2, 3. If I moved one to 4 >> and added another to 3, I'd expect the order to change. However, as >> long as I didn't change what was plugged into each socket, I >> certainly wouldn't expect a change. > > That's not guaranteed, since it's not part of any ABI. Can you give a case where the order does change? >> Since I boot from sda, then I'd expect all sata drives to be detected >> and set before any usb or firewire drives. > > That's also not guaranteed, for the same reason. > > USB hubs, followed by any attached USB storage devices, might end up > calling into sd_probe *long* before PCIe SATA does, if you hit the wrong > internal kernel timing. It's an inherent race condition; the only way > to guarantee it would be to return to a single-threaded device probe > model in the kernel, but that was explicitly changed to be parallel back > in one of the 2.6 kernels. Well, as I said above, my kernel actually discovers the usb drive before the 2nd sata drive, but assigns them properly. This is a good discussion. I did look for a usb drive in my spare parts, but didn't have one, so I went to the store and spent $9 for a 16G usb drive. I splurged because the 4G drive was $4. :) -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
