Bruce Dubbs wrote: > Bryan Kadzban wrote: > >> 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).
There might be an outcry, but I don't think it'd be that big. There have been plans to require udev, by dynamically assigning major/minor numbers, for years. (devtmpfs didn't exist at the time.) Once that's in place, the response to any such outcry would be "use the symlinks that udev provides", since those are stable regardless of discovery order. > Yes, If you boot to a different drive, the order will change. I'd be extremely surprised if the drive you boot to has any effect. 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. :-) >> 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. That's not guaranteed, since it's not part of any ABI. > 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. >> 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. Right, but you can get both (never having to change fstab for a similar change, and never having to care about device discovery order), with /dev/disk/by-id symlinks. (And forcing a change to fstab means that it's impossible to revert to the old kernel without patching up fstab with init=/bin/bash or equivalent, as well. Not being able to downgrade is not the best place to be in. :-) Not that this is very relevant anymore.) > 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. But you're in an inherently unstable state, which I can't in good conscience recommend for users.
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
