Bryan Kadzban wrote: > Just *booting a different kernel* might change the order eventually. > There's no guarantee in the kernel <-> user ABI that disk devices > (including the PCI or PCIe controllers that host disk devices, but > *also* the devices themselves) are always discovered in the same order > from one version to the next. > > 3.7 might change it so that PCI/PCIe devices scan in the opposite order > on their bus, or so that on a given disk controller, devices are > discovered in backwards order. That's rather unlikely, of course, but > it's not something that can be discounted. > > What's rather more likely is an eventual change to probe disks in > parallel across controllers, at which point everything will look like > USB in terms of ordering guarantees. (In particular, there are none.) > That would be either assigning each PCI/PCIe bus to a separate thread, > or assigning each IDE/SCSI/SATA/whatever "bus" to a separate thread, or > both.
I think you are stretching here a bit. I think there would be quite an outcry if sda and sdb were swapped just by rebooting (to the same drive). Yes, If you boot to a different drive, the order will change. >> Plenty of things to change device node creation for each disk in many >> configurations. >> >> On the other hand, when not changing anything, it's pretty static and >> doesn't change. > > Today, at least. That's only because nobody has merged (or maybe nobody > has written) a patch to assign each disk "bus" to a separate thread for > disk discovery (as above), and have them go in parallel. > > Still doesn't matter for only one disk, but leaving a USB device plugged > in across a boot could still break it. I'd rather use something that's > guaranteed; one of labels, UUIDs, device IDs, or device paths. 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. Since I boot from sda, then I'd expect all sata drives to be detected and set before any usb or firewire drives. > Also, from earlier: > > Bruce Dubbs wrote: >> Bryan Kadzban wrote: >> >>> I will also note that using /dev/disk/by-id/ links allowed me to >>> survive the IDE -> libata transition (/dev/hd* to /dev/sd*) with >>> zero userspace changes. >> >> I don't recall running into that problem. ISTR that hdx mapped to >> sdx without issue. > > It didn't. You had to change hdx to sdx in /etc/fstab, because the old > hdx nodes didn't exist anymore in the libata kernel. Of course it's > possible that this upgrade happened over a system rebuild as well, I > don't know... > > I had to make zero changes other than installing the new kernel. :-) Yes, I had to change fstab, but the order remained the same: a->a, b->b, c->c. Of course the partitions remained the same too. BTW, my system boots just fine (and pretty fast) with udev disabled completely, so no symlinks are required at all in the simple sata configuration. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
