(Hooray life. Got busy the last couple of days. Getting back to these threads now...)
Bruce Dubbs wrote: > 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. The current kernel code might prevent this from happening, I don't know for sure. But I don't trust that this code will never be changed to allow it, because AFAIK there's no spec to force the assignment to be static. And if that ever happens, I doubt it'll be reverted, based on similar situations with things like NICs. > On my LFS development system, dmesg says the drives are discovered i > the order of scsi 0:0:0:0 (sda), usb 2-4, I'm pretty sure usb2-4 isn't a drive, it's either a device or an interface. The sd_probe call won't happen until the device gets assigned a SCSI address (I believe sd_probe is what assigns that address, actually). > 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. The only reason that's showing up after the others is because the USB probe stuff (enumerating all the hub ports and handling the hotplug callbacks inside the kernel for whatever is connected to each one) takes so long. If something random causes the callbacks to show up faster, the USB drive might get either sdc or sdb. (Or, if usb2-4 shows up earlier, it might even get sda.) > 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 udev finds out which name to use by querying the disk device for its various identifying strings. So it runs ata_id on /dev/sdb, and finds that that program returns ID_BUS=ata, ID_MODEL=ST3750330AS, and ID_SERIAL=ST3750330AS_9QK0X0PX, so it creates that symlink. It also runs path_id, scsi_id, etc., or executes the udev builtins, and creates the appropriate links for those methods. Wherever sdb gets discovered in the future, ata_id will continue to find the same device type, the same model, and the same serial, so the symlink name will always point to the right device. (Even if you move it around inside the machine.) >>> 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? Not offhand. It's mostly that I don't trust the people involved in kernel hotplug to not change it, because nothing prevents them from doing so. :-) >>> 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. That's still a race. It's not assigning them explicitly in that order, it's just that the USB discovery process (almost?) always takes long enough that sd_probe is called last for the USB disk.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
