[CentOS] Controlling the order of /dev/sdX devices?

[Lamar Owen]

On Thursday, March 31, 2011 10:24:42 am Phil Schaffner wrote:
> I hope you are aware that you are using a very obsolete OS with a lot of 
> known (i.e. exploitable) security holes and bugs that have subsequently 
> been fixed.

No to pick on you, Phil, but the OP may have very specific reasons to run that particular system; and he may not.  And while the advice 'please update' is a good thing, it doesn't really answer the question at hand.

Cal, you might want to rethink your udev script for one; also, module load order may not be something you can easily control; while you might easily load the RAID controller's module first, then load the others, that is no guarantee that the RAID controller will be detected first.  These days, you have to be resilient to drive device changes, even for the root filesystem.  And that module load order will be found in the initramfs (initrd), and you'd have to go in and hack that to get things to load in the order you want.  But then that will all break when you go to C6 or later, as udev is used from the initrd using dracut, and hardcoding module load order becomes much more difficult.

For instance, I have a Fedora 14 box (which acts much like a CentOS 6 box would act, and not like a C5 box acts, but that's beside the point) where different boots can bring up a different device order; in this particular case, I have a 3Ware RAID controller from which I boot and which has four 250GB SATA drives on it in RAID5 for boot and root, then a SATA/eSATA 64-bit PCI-X board (two internal SATA, two eSATA, 3Gb/s ports) with two interal 750GB drives in MD RAID 1, and I do boot with eSATA drives plugged in, or not, at different times.  This box is also connected via dual-port Fibre Channel to our SAN, and it has several multipath LUNs associated with that.  

My last detected SCSI device is currently /dev/sdab, but that is without any eSATA or USB devices, so I could see /dev/sdad or higher on occasion; and because it's set up with multipathing based on scsi_dh_emc, it doesn't have contiguous device names, either (the current setup is: sda, sdb, sdf, sdg, sdi, sdj, sdp, sdu, sdw, sdx, sdy, sdab).  This is not only subject to change at each boot, but it's subject to change while the system is running, thanks to scsi_dh_emc, and thanks to there being more than even two paths to a given LUN.

I haven't had any trouble, even when the RAID array was the one that got detected dead last, as /dev/sdac (in /etc/fstab, /boot is mounted by UUID, and root by LVM).  

But I'm also not automounting hotplugged eSATA drives, either.  USB devices get automounted into /media with their labels as they should; that's the out-of-box behavior.

Trying to get specific about device order is going to become increasingly difficult as time goes on; you might consider trying to get away from hardcoded drive names.

But in the short term, try starting your hotplugged devices at /dev/sde or f and see if that fixes the /dev/sdd not working issue.