dealing with dual path hp disk array

[vaxbrat]

Does anyone have any experience dual pathing an HP server under gentoo? I have a fairly new dual xeon server with dual Emulex Thor fiber cards going into a dual MSA1000 controlled array. This is a dual boot with win2k3 so I have already used the acu utility under that to configure 6 raid5 volumes with 4 already done as ntfs. I did the final two as xfs for the moment.

Under gentoo with a gentoo-sources-2.6.21 kernel, the Thor cards get recognized and present the volumes as follows:

/dev/sda - /dev/sdf : The path through the first msa1000
/dev/sdg - /dev/sdl : The path through the second msa1000

At the moment, the second msa appears to be the active path since I can fdisk and mount devs sdg through sdl while sda-sdf give i/o errors. I haven't tried power cycling the msa's and bringing them up in different order yet to see how the rug would get pulled out from under things.

At first glance, all of the HP Linux offerings are slanted to be binary x86 or x86_64 rpms for either RHEL 3&4, SUSE or UnitedLinux. I may rummage through them later to see whether I can get the acu stuff running under gentoo. Their secure path utility appears to be their answer to the multipath/failover issue, but as mentioned, its binary rpm's

[vaxbrat]

After pulling power on the active msa1000 and reseating, it looks like the volumes get another set of /dev/sd<x> nodes assigned. That is I now had /dev/sdm - /dev/sdp as the active path. Yech!

So it looks like the current failover strategy for me is to reboot when I lose an msa1000. I've changed my fstab to use the disk labels instead of physical device name to handle the shifting device names. So before I would have /dev/sda1, now it's what the filesystem was labeled with when created ie: /dev/disk/by-label/bay1_left where "bay1_left" was the label.

Next problem was the xfs filesystem. When I originally did mkfs.xfs I didn't put labels on the two new filesystems I created. So I guess I'll have to go back to slap labels on them via xfs_admin.

I'll have to see what happens when I pull one of the fibers. Not sure whether the Thor drivers will be smart enough to figure out a new active path via the second fiber. I suspect I may be able to plug it back in and get a soft recovery, but we'll see.

[vaxbrat]

My latest headache with this server is an Adaptec U320 scsi controller which has an ADIC Scaler 24 tape library with a pair of IBM LTO3 tape drives. This all shows up and works when Win 2k3 is up and running.

First headache: IBM is only doing binary drivers at the moment for the LTO3 for RHEL 4, SUSE 8 or 9 and the other usual suspects. I'm at 2.6.21 and these things are back at 14 or 16 or whatever RHEL 4 is. I was thinking that I could get by with mt and the generic scsi tape stuff but ran into....

Second headache: The aic79xx driver loads but does not find anything at all attached. No LTO 3's and no robot arm. There's a string of "Selection timeout on A:# 0 SCBs aborted" for each unit and lun probed. When I tried to turn on Debug, I wasn't even seeing that. Guess I'll have to get messy and start messing with device drivers and printf statements. I tried to usual PCI=routeirq and PCI=noacpi tricks on boot, but no luck. I guess that would only have meant something if I wasn't seeing the Adaptec in the first place.

I might try some mischief with Fedora 7 on here now that it's out. That's supposedly kernel 21 also. I also had FC6 on here at one point but nuked it before doing much of anything and installed gentoo. It will give me some idea of how to set up the Emulex fiber channels to boot stuff.