tools target for SLES9 SP2 and RHEL4 U2

tools target for SLES9 SP2 and RHEL4 U2

[christophe varoqui]

Alasdair, Lars,

where do you want to go with the multipath tools for your next distro
release ?

Should we stabilize a 0.4.5 out of the git head, or do you want bugfixes
in there backported to 0.4.4 ?

If the former is prefered, I'll start tagging the tree more regularly to
provide tarballs and widen the audience. It will also be good to freeze
a list of shortcomings to address for the release, and decide on a
deadline.

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

Re: tools target for SLES9 SP2 and RHEL4 U2

[Alasdair G Kergon]

On Thu, Jun 09, 2005 at 08:16:42PM +0200, christophe varoqui wrote:
> where do you want to go with the multipath tools for your next distro
> release ?
 
We discussed this on this week's conference call, and we'd both like
a period of stabalisation until early next month i.e. only bug fixes 
applied for a few weeks.

Alasdair
-- 
agk@redhat.com

Re: tools target for SLES9 SP2 and RHEL4 U2

[Alasdair G Kergon]

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

Yes - both distributions are basing their next package on your 
current git head.

Alasdair
-- 
agk@redhat.com

Re: tools target for SLES9 SP2 and RHEL4 U2

[christophe varoqui]

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
> 
> Yes - both distributions are basing their next package on your 
> current git head.
> 
ok,

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.

StorageWorks hardware relied on the daemon to keep the paths in failover
path groups to be in active state. That is no longer the case, now that
we keep the DM path state in sync with checker states.

I guess to correct way to get back to a working model is to implement
the DM path activation in a hardware handler. Dave Olien and Mike
Christie have worked on such a handler. It needs debuging and testing.

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

Re: tools target for SLES9 SP2 and RHEL4 U2

[Mike Anderson]

Alasdair G Kergon [agk@redhat.com] 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
> 
> Yes - both distributions are basing their next package on your 
> current git head.
> 

What about multipathd's use of uevents for dm updates and the distro
kernels currently not supporting this capability. Will a person just have
to restart multipathd if one changes the dm config and a newer kernel is
not being used?

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: tools target for SLES9 SP2 and RHEL4 U2

[Christophe Varoqui]

On Thu, Jun 09, 2005 at 11:10:33PM -0700, Mike Anderson wrote:
> Alasdair G Kergon [agk@redhat.com] 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
> > 
> > Yes - both distributions are basing their next package on your 
> > current git head.
> > 
> 
> What about multipathd's use of uevents for dm updates and the distro
> kernels currently not supporting this capability. Will a person just have
> to restart multipathd if one changes the dm config and a newer kernel is
> not being used?
> 
And should we consider moving the libdevmapper event daemon framework for 0.4.5 ?

Regards,
cvaroqui

Re: tools target for SLES9 SP2 and RHEL4 U2

[Lars Marowsky-Bree]

On 2005-06-09T23:10:33, Mike Anderson <andmike@us.ibm.com> wrote:

> > > Should we stabilize a 0.4.5 out of the git head
> > Yes - both distributions are basing their next package on your 
> > current git head.
> What about multipathd's use of uevents for dm updates and the distro
> kernels currently not supporting this capability. Will a person just have
> to restart multipathd if one changes the dm config and a newer kernel is
> not being used?

We'll need a workaround for that, or back it out for our distribution
and go back to the signal version...


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

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

[Axel Thimm]

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

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?

Thanks!

> StorageWorks hardware relied on the daemon to keep the paths in failover
> path groups to be in active state. That is no longer the case, now that
> we keep the DM path state in sync with checker states.
> 
> I guess to correct way to get back to a working model is to implement
> the DM path activation in a hardware handler. Dave Olien and Mike
> Christie have worked on such a handler. It needs debuging and testing.
> 
> Regards,

-- 
Axel.Thimm at ATrpms.net

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

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

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

[christophe varoqui]

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.

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.

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

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

[Axel Thimm]

[-- 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 --]

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

[christophe varoqui]

On dim, 2005-06-12 at 16:33 +0200, Axel Thimm wrote:
> 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?
> 
I guess yes.
You'll know soon enough in your testing ...

What you have to be careful about is the daemon reinstating paths in the
inactive PG. If it does so, you should be safe.

> > 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)?
> 
Yes, there is a performance cost with all topologies involving multiple
paths in 1 PG. True for multibus and group_by_serial in your setup.

multibus as a default is an error, which is corrected in the devel
branch. group_by_serial would be the adequate policy, left alone this
performance problem that will eventually gets sorted out.

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

Re: tools target for SLES9 SP2 and RHEL4 U2

[Lars Marowsky-Bree]

On 2005-06-10T12:47:11, Lars Marowsky-Bree <lmb@suse.de> wrote:

> > What about multipathd's use of uevents for dm updates and the distro
> > kernels currently not supporting this capability. Will a person just have
> > to restart multipathd if one changes the dm config and a newer kernel is
> > not being used?
> We'll need a workaround for that, or back it out for our distribution
> and go back to the signal version...

So any comments on this one, christophe?

Maybe fallback to signals if the kernel version is too old? Or should we
maintain a separate patch for the distribution?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: tools target for SLES9 SP2 and RHEL4 U2

[Christophe Varoqui]

On Tue, Jun 14, 2005 at 12:34:50PM +0200, Lars Marowsky-Bree wrote:
> On 2005-06-10T12:47:11, Lars Marowsky-Bree <lmb@suse.de> wrote:
> 
> > > What about multipathd's use of uevents for dm updates and the distro
> > > kernels currently not supporting this capability. Will a person just have
> > > to restart multipathd if one changes the dm config and a newer kernel is
> > > not being used?
> > We'll need a workaround for that, or back it out for our distribution
> > and go back to the signal version...
> 
> So any comments on this one, christophe?
> 
> Maybe fallback to signals if the kernel version is too old? Or should we
> maintain a separate patch for the distribution?
> 
I'm sure you understand this patch is rather invasive.
I'm clearly reluctant to maintain backward compatibility on this point.

Distributors assuming the burden of it is not nice either.

Have you pondered backporting the uevent kernel patch : it seems rather safe (from my seat, that is :)

Regards,
cvaroqui

Re: tools target for SLES9 SP2 and RHEL4 U2

[Lars Marowsky-Bree]

On 2005-06-14T13:44:34, Christophe Varoqui <christophe.varoqui@free.fr> wrote:

> I'm sure you understand this patch is rather invasive.  I'm clearly
> reluctant to maintain backward compatibility on this point.
> 
> Distributors assuming the burden of it is not nice either.

Yes, I looked at how much the code diverged, and got pretty frightened
to be maintaining such a patch.

> Have you pondered backporting the uevent kernel patch : it seems
> rather safe (from my seat, that is :)

That might indeed be the cleanest solution. What exactly is needed for
it to work for multipath-tools?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: tools target for SLES9 SP2 and RHEL4 U2

[Christophe Varoqui]

On Tue, Jun 14, 2005 at 02:00:27PM +0200, Lars Marowsky-Bree wrote:
> On 2005-06-14T13:44:34, Christophe Varoqui <christophe.varoqui@free.fr> wrote:
> 
> > I'm sure you understand this patch is rather invasive.  I'm clearly
> > reluctant to maintain backward compatibility on this point.
> > 
> > Distributors assuming the burden of it is not nice either.
> 
> Yes, I looked at how much the code diverged, and got pretty frightened
> to be maintaining such a patch.
> 
> > Have you pondered backporting the uevent kernel patch : it seems
> > rather safe (from my seat, that is :)
> 
> That might indeed be the cleanest solution. What exactly is needed for
> it to work for multipath-tools?
> 
For now only the following events :

- block dev add
- block dev remove

When transport uevents get implemented we may want to use them too, but it is not the case in HEAD.

Regards,
cvaroqui

Re: tools target for SLES9 SP2 and RHEL4 U2

[Alasdair G Kergon]

On Tue, Jun 14, 2005 at 02:00:27PM +0200, Lars Marowsky-Bree wrote:
> > Have you pondered backporting the uevent kernel patch : it seems
> > rather safe (from my seat, that is :)
> That might indeed be the cleanest solution. What exactly is needed for
> it to work for multipath-tools?
 
Or produce something in userspace that emulates what uevent is being
used for.
 
Alasdair
-- 
agk@redhat.com

Re: tools target for SLES9 SP2 and RHEL4 U2

[Lars Marowsky-Bree]

On 2005-06-14T14:48:18, Christophe Varoqui <christophe.varoqui@free.fr> wrote:

> For now only the following events :
> 
> - block dev add
> - block dev remove
> 
> When transport uevents get implemented we may want to use them too, but it is not the case in HEAD.

The only thing which seems to generate uevents in 2.6.12-rc6-mm1 seems
to be mount/umount though?

Am I spectacularly missing something? ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: tools target for SLES9 SP2 and RHEL4 U2

[Christophe Varoqui]

On Tue, Jun 14, 2005 at 03:57:53PM +0200, Lars Marowsky-Bree wrote:
> On 2005-06-14T14:48:18, Christophe Varoqui <christophe.varoqui@free.fr> wrote:
> 
> > For now only the following events :
> > 
> > - block dev add
> > - block dev remove
> > 
> > When transport uevents get implemented we may want to use them too, but it is not the case in HEAD.
> 
> The only thing which seems to generate uevents in 2.6.12-rc6-mm1 seems
> to be mount/umount though?
> 
> Am I spectacularly missing something? ;-)
> 
the kobject plug maybe :)

Re: tools target for SLES9 SP2 and RHEL4 U2

[Lars Marowsky-Bree]

On 2005-06-14T16:08:21, Christophe Varoqui <christophe.varoqui@free.fr> wrote:

> > Am I spectacularly missing something? ;-)
> the kobject plug maybe :)

Ah. I missed the overwrite of kobject_hotplug(). Right. Sorry. Ignore
the noise ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"