[dm-devel] Re: StorageWorks failover model (was: tools target for SLES9 SP2 and RHEL4 U2)

[Axel Thimm]

On Sun, Jun 12, 2005 at 02:31:26PM +0200, christophe varoqui wrote:
> On dim, 2005-06-12 at 14:21 +0200, Axel Thimm wrote:
> > Hi,
> > 
> > On Thu, Jun 09, 2005 at 09:34:53PM +0200, christophe varoqui wrote:
> > > On jeu, 2005-06-09 at 20:15 +0100, Alasdair G Kergon wrote:
> > > > On Thu, Jun 09, 2005 at 08:16:42PM +0200, christophe varoqui wrote:
> > > > > Should we stabilize a 0.4.5 out of the git head
> > > be aware I broke the StorageWorks failover model to satisfy the
> > > expressed need to proactively fail paths in the DM when the checkers see
> > > them going down.
> > 
> > What does that mean for StorageWorks users? I'm currently setting up a
> > StorageWorks EVA3000 from scratch based on FC4 final. Will I stumble
> > into any pitfalls, or would that only affect gits users?
> > 
> 0.4.4 should be ok. I don't know what FC packagers did though.

It's 0.4.4.2 with a couple of patches. Is that still OK?

> Also be aware you'll be best served using the failover policy for now :
> there is a 20% performance impact with multi-path per PG.

The default multipath.conf ships with path_grouping_policy multibus
(e.g. all 4 paths in one path group on a 2x active/2x failing
controller setup). I understand that doing round robin over the active
and failed paths will make performance drop.

But what about path grouping with group_by_serial (like tur did,
e.g. an active path group and a failing path group)? Is that eating
performance, too? So I should prefer a path per PG (failover)?

Thanks!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20050612/2e486f85/attachment.sig>