[CentOS] RHEL-6 vs. CentOS-5.5 (was: Static assignment of, SCSI device names?)

Les Mikesell wrote:
>
> On 1/30/11 1:37 PM, Chuck Munro wrote:
>> > Hello list members,
>> >
>> > My adventure into udev rules has taken an interesting turn.  I did
>> > discover a stupid error in the way I was attempting to assign static
>> > disk device names on CentOS-5.5, so that's out of the way.
>> >
>> > But in the process of exploring, I installed a trial copy of RHEL-6 on
>> > the new machine to see if anything had changed (since I intend this box
>> > to run CentOS-6 anyway).
>> >
>> > Lots of differences, and it's obvious that RedHat does things a bit
>> > differently here and there.  My focus has been on figuring out how best
>> > to solve my udev challenge, and I found that tools like 'scsi_id' and
>> > udev admin/test commands have changed.  The udev rules themselves seem
>> > to be the same.
> Do any of the names under /dev/disk/* work for your static identifiers?  You
> should be able to use them directly instead of using udev to map them to
> something else, making it more obvious what you are doing.  And are these names
> the same under RHEL6?
>

I was happy to see that device names (at least for SCSI disks) have not 
changed.  The more I look into the whole problem the more I realize that 
I've overstated the difficulty, now that I know how to map out the 
hardware path for any given /dev/sdX I might need to replace.  I've 
never dug as deeply into this before, mostly because I never could find 
the spare time.

I'm happy with simply writing a little script which accepts a /dev/sdX 
device name argument and reformats the output of:
  'udevadm info --query=path --name=/dev/sdX'
to extract the hardware path.  It's a bit cleaner than the current 
RHEL-5/CentOS-5 'udevinfo' command.

Using the numeric path assumes knowledge of how the motherboard sockets 
are laid out and the order in which I/O controller channels are 
discovered, of course.  It's then not difficult to trace a failed drive 
by attaching little tags to the SATA cables from the controller cards.

The real key is to carefully label each SATA cable and its associated 
drive.  Then the little mapping script can be used to identify the 
faulty drive which mdadm reports by its device name.  It just occurred 
to me that whenever mdadm sends an email report, it can also run a 
script which groks out the path info and puts it in the email message. 
Problem solved :-)

So even though I figured out how to add 'alias' symlink names to each 
disk drive, I'm not going to bother with it.  It was a very useful 
learning experience, though.

Chuck