[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Thanks! So pool_mp will work with an active-active array like a

I tried pool on powerpath, and it works very well. 

Thanks, jacob 

-----Original Message-----
From: linux-cluster-bounces redhat com
[mailto:linux-cluster-bounces redhat com] On Behalf Of Jonathan E
Sent: Tuesday, June 07, 2005 11:57 AM
To: linux clustering
Subject: Re: [Linux-cluster] GFS Multi-pathing and trespassed LUNs

On Jun 6, 2005, at 1:13 AM, <JACOB_LIBERMAN 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

> 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

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,

Linux-cluster mailing list
Linux-cluster redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]