* Christophe Varoqui > Yes, "sg_start -s /dev/sdb 1" is not an adequate mean to force a > host-driven failover for the clariion hardware. You need the > trespass tool included in recent sg3_utils package. Ohh, I wasn't aware this utility already existed. I'll try it out as soon as I can. My test box has crashed though and for some reason doesn't reach GRUB so I cannot use the serial console to fix it. :-( So I need to take a trip to our colo in order to test more; I'll try to find time to do it today. However, before it crashed I found out another way of doing it, which seemed to work more predictably. I was meaning to wait until I could do a second test before I sent the report here, but oh well, here goes: If I set "failover mode" in Navisphere to be "2", the CLARiiON's behaviour changes to automatically migrate/trespass the LU, if one of the controllers receives I/O. With this setup I believe I can use the tur path checker and no hardware_handler. Now, I also found out that my testing method of removing the controllers as members from the test box' zone is a tad suboptimal, because even though I remove only one path, both paths are affected in a very short period of time. I discovered this by running sg_turs on both paths in a 20ms loop while removing one path - it started hanging (probably waiting for some timeout) on the path I actually removed, while one sg_turs invocation on the still present path failed with "bus has been reset" or some such. As I do pretty heavy I/O to the LU while failing paths, this is probably more than enough for multipathd to conclude that both paths are down, and is probably also the reason why I need queue_if_no_path to avoid file system corruption. Had I been able to yank fibres instead I can easily imagine that it had worked. However, I think there's a genuine bug in multipathd here - after having failed both paths it never recovers them. They get stuck as failed seemingly forever, even though it logs that it's checking paths, and in spite of the fact that one of the paths only were failed in a split second. sg_turs towards this path runs OK also. However, if I restart multipathd manually, it rediscovers the path immediately and start sending I/O to it. So it seeems to me that something's not quite right with multipathd here - I'll be happy to provide any more info you need if you agree. If this issue is solved I'd say it's quite usable for production, if it also passes a few lenghty stability tests of course. There's a few snags to running the CLARiiON like this, though. If I trespass the LU in the Navisphere interface, it is immediately moved back to the controller it was on, because multipathd is sending I/O there (trespassing doesn't fail the path). Also, initiating a trespass from the host (can be done by simply attempting to read the partition table or something on the inactive path) yields the same result. I don't know if the CLARiiON sends some hint down the fibre that the LU has been migrated, but if it does, it's ignored. I'm guessing, but using the trespass utility you spoke of will probably also just be a no-op if I am to continue using this automatic trespass mode. This is no big deal for me though, however I would really like to find out how to make multipathd's affection for the first controller (or the sd* with the lowest minor, possibly) go away so that I can distribute LUs between the controllers manually. That's not very important if I only have a few connected systems with multipath-tools (as PowerPath heeds what controller I set as the default LU owner in Navisphere), but if I am to replace PowerPath with multipath-tools on all connected systems (something I would very very very much like to do :-), this is a blocker, I'm afraid. Thanks, -- Tore Anderson