[CentOS] add on sata card relabeling drives, installation

[Lamar Owen]

On Friday, September 30, 2011 11:41:02 AM Les Mikesell wrote:
> Because I can.  Why wouldn't you?   
...
> That doesn't any more sense than having to label all your shipping
> containers descriptively before you know what you are going to put in
> them.  And besides, most of the labels are applied by the installer
> without user input.

While finding the corner cases seems to be your specialty, Les, recognize that there will always be a corner case not covered by any filesystem labeling/naming scheme, no matter what scheme is used.

It's not at all hard to change the labels after the install.

Linux disk device names aren't reliable (with iSCSI and other SAN technologies they never have been).  

LVM has name collision issues (if two sets of one volume group name are found, hilarity ensues, part of the reason why LVM volume group names picked by the installer are now in EL6 based on hostname and not just generic names as before).

Labels of course have their own collision issues, but a label is the one thing that is the most easily modified by the user; use the chosen filesystem's labeling command (e2label for ext2/3/4; other filesystems have their own) and change it in /etc/fstab as well; next reboot it will get picked up.  Labels have serious multipathing issues.

UUID is, IMHO at least, the worst of all worlds due to the length and the user-unfriendliness of it all (it's been the Ubuntu default for a while, though!).  It is guaranteed unique (until you use complete clones), but is the most difficult to change and use.

Doing it by controller, channel, and logical unit makes a lot of sense until you change things around a few times (and with SAN technologies change is very easy).  My boot drive on one box gets a new drive 'letter' (yuck, DOSism at its worst!) nearly every boot due to the highly dynamic and multipathed nature of  of the SAN fabric connection to it, and the fibre channel HBA is being enumerated before the boot RAID controller (3Ware).  

And it needs to be that way because of the different PCI-X speeds involved, as well as cable lengths and clearance issues inside the 2U server's chassis.  But having /dev/sdag as my boot drive doesn't bother me in the least; everything is either LVM or label-based mounting, and I haven't had any collision problems (but multipath problems are a different story).  

But my multipathing issues relate to my situation being one of those corner cases (the normal multipathing assumes an A and a B side redundancy from HBA ports through the fabric to the storage processors to the backend loops; while I will soone be there I am not right now, with machines seeing four paths to every LUN and not just two).  When I get things into the recommended dual-path HA state either the standard EL-provided multipathing or the EMC PowerPath routing will work as designed, so I can't actually complain that my situation is working properly.