William Harrington wrote: > > On Oct 6, 2012, at 3:51 PM, Bruce Dubbs wrote: > >> I don't think so. I don't use UUID or LABEL in fstab, but >> /dev/sd?? would only change if I did somthing with fdisk like >> deleting a partition and splitting two in it's place. I suppose >> deleting an extended partition could do it also. > > Using external firewire or usb devices will change devices at times. > Enabling onboard or disabling onboard disk controllers will change > order at times. Inserting a drive and changing port numbers or boot > order will change the order at times.
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. > 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. 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. :-)
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
