[Linux-cluster] GFS Multi-pathing and trespassed LUNs

Jonathan E Brassow jbrassow at redhat.com
Tue Jun 7 16:57:11 UTC 2005


On Jun 6, 2005, at 1:13 AM, <JACOB_LIBERMAN at Dell.com> wrote:

> This is a question regarding GFS native multipathing support:
>
> I have a typical redundant mesh topology -- 2 switches, 2 HBAs per 
> host,
> 2 storage processors. I create the pool device per the procedure
> outlined in RedHat KB 4343 and then mount it locally. This works fine.
> However, if I trespass the LUN between SPs during a write operation, I
> lose all access to it. I have tried pool_mp with both failover and 
> round
> robin policies.

Unfortunately, pool multipathing does not do any special handling when 
switching between LUNs - it assumes all LUNs are active/active.  This 
does not seem to be the case in your instance, as trespassing LUNs is a 
way to do active/passive multipathing (IIRC).  So, to answer your 
questions....

> Here are my questions:
> 1. Is there any way to accommodate trespassed LUNs via pool_mp?

Short answer: no.

Long answer: yes.  However, you would have to purchase a copy of 
PowerPath and use that for multipathing.  Pool understands powerpath 
devices and will sit happily upon them - ignoring the other paths to 
the device.

With multipathing in RHEL4, underlying hardware idiosyncrasies are 
dealt with properly.

> 2. Do you need to do anything special (ie remount the LUN, run
> partprobe, etc.) to accommodate a trespassed LUN?

If it were possible to make the non-useable LUNs unseen to linux, at 
least you would have fault tolerance down to the device...  However, 
this would mean that if a controller failed, you wouldn't be able to 
handle it.

> 3. are the pool_mp policies primarily designed to accommodate front-end
> failures? (IE cables, HBAs, switch ports.)

Again, pool MP requires that all paths are active/active.

hope this helps,
  brassow




More information about the Linux-cluster mailing list