
On Tue, Apr 22, 2014 at 11:52:51PM -0700, Rick Moen wrote:
Quoting Craig Sanders (cas@taz.net.au):
i've had it happen on kernel upgrades, and even on reboots - a new version of udev or something loaded modules in a different order, so drives got detected in a different order.
I can envision that happening if your kernel suddenly changed from old drivers/ide SATA drivers to modern libata one - a one-time changeover that occurred sometime early in the 2.6 kernel series, if I remember what I wrote on http://linuxmafia.com/faq/Hardware/sata.html correctly. I envision that happening if you use multiple, different drive technologies (e.g., PATA and SCSI).
having multiple drive controller technologies - sata and sas, for example - is not at all uncommon.
I have having a difficult time envisioning it happening otherwise. Your master drive on the first PATA chain will always get the first PATA device assignment, your third SCSI device on a SCSI chain will always get the third SCSI device name allocated to that chain, and so on.
it's also not at all uncommon for motherboards to have multiple different kinds of SATA (or even SAS) ports, requiring different drivers - e.g. sata_mv, sata_nv, ahci. the order that these drivers will load is *not* guaranteed by anything. in fact, it's explicitly NOT guaranteed which is why the advice is to use UUIDs or LABELs rather than device names. load the sata_mv driver before ahci and suddenly your /dev/sda is now /dev/sde or /dev/sdj or something. most people don't have the knowledge or skill to deal with this happening, so it's best for most people to just follow the default of using UUIDs (or LABELs) and avoid the problems that drive re-numbering will cause.
In short, I suspect that the applicable scenarios are either very rare or involve hardware practices about which the best overall comment is Don't Do That, Then.
to the contrary, they're entirely normal and fairly common scenarios. the fact that you haven't encountered it just means you're lucky, not that your experience is common. craig -- craig sanders <cas@taz.net.au> BOFH excuse #362: Plasma conduit breach