Re: StorageWorks failover model (was: tools target for SLES9 SP2 and RHEL4 U2)

[Axel Thimm <Axel.Thimm@ATrpms.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1574 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]