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:
pgpBmOmYf9u4D.pgp
Description: PGP signature