Future of md multipath

Future of md multipath

[Christoph Hellwig]

Just noticed that we still have the old md-based multipath driver
in the tree, which seem to not have gotten any attention since we
got dm multipath.

Is there any reason to keep it or should we deprecate it and kill
it after a couple of kernel releases?

Re: Future of md multipath

[Neil Brown]

On Tuesday March 3, hch@lst.de wrote:
> Just noticed that we still have the old md-based multipath driver
> in the tree, which seem to not have gotten any attention since we
> got dm multipath.
> 
> Is there any reason to keep it or should we deprecate it and kill
> it after a couple of kernel releases?

I'm in favour of deprecating it.  Whenever I hear of people using it I
suggest dm-multipath, but there could people I don't here about.
I think the upcoming mdadm-3.0 will need a compile-time option to
enable multipath, so people will only get it if they really really
want it.

So feel free to propose patches.

Thanks :-)

NeilBrown

Re: Future of md multipath

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

also sprach Neil Brown <neilb@suse.de> [2009.03.05.0349 +0100]:
> I'm in favour of deprecating it.  Whenever I hear of people using it I
> suggest dm-multipath, but there could people I don't here about.
> I think the upcoming mdadm-3.0 will need a compile-time option to
> enable multipath, so people will only get it if they really really
> want it.

How do you propose a distro to deal with this? Keep it enabled for
a certain time (with a deprecation warning?) and then just to close
the doors on users who still need it?

How long will you support it after deprecation?

I understand that dm-multipath is more favourable, but unless
there's a riskless way to convert mdadm multipath into dm-multipath
on old systems, I don't think we have the option of deprecating it,
unless deprecation lasts for several years.

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the perfect gun is an idealist without any ideal."
                                                  -- mc 900 ft jesus

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Future of md multipath

[Neil Brown]

On Thursday March 5, madduck@debian.org wrote:
> also sprach Neil Brown <neilb@suse.de> [2009.03.05.0349 +0100]:
> > I'm in favour of deprecating it.  Whenever I hear of people using it I
> > suggest dm-multipath, but there could people I don't here about.
> > I think the upcoming mdadm-3.0 will need a compile-time option to
> > enable multipath, so people will only get it if they really really
> > want it.
> 
> How do you propose a distro to deal with this? Keep it enabled for
> a certain time (with a deprecation warning?) and then just to close
> the doors on users who still need it?
> 
> How long will you support it after deprecation?
> 
> I understand that dm-multipath is more favourable, but unless
> there's a riskless way to convert mdadm multipath into dm-multipath
> on old systems, I don't think we have the option of deprecating it,
> unless deprecation lasts for several years.

Always the practical one, aren't you :-)

I wonder how hard it would be to get mdadm to assemble a multipath
using the 'dm' code rather than the 'md' code....
Or to get the md layer in the kernel to hook in to the dm multipath
implementation.

I think it is probably worth putting in a printk now to say "You
should probably be using dm-multipath".  But we probably do need to
leave the code there for a while longer..

NeilBrown

Re: Future of md multipath

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

also sprach Neil Brown <neilb@suse.de> [2009.03.06.0632 +0100]:
> > I understand that dm-multipath is more favourable, but unless
> > there's a riskless way to convert mdadm multipath into dm-multipath
> > on old systems, I don't think we have the option of deprecating it,
> > unless deprecation lasts for several years.
> 
> Always the practical one, aren't you :-)

Goes with the territory. Debian does not need to make long term
support guarantees. They're inherent in our quality assurance,
security support, and chaotic organisation. :)

> I wonder how hard it would be to get mdadm to assemble a multipath
> using the 'dm' code rather than the 'md' code....
> Or to get the md layer in the kernel to hook in to the dm multipath
> implementation.

A migration isn't possible?

> I think it is probably worth putting in a printk now to say "You
> should probably be using dm-multipath".  But we probably do need
> to leave the code there for a while longer..

Maybe it would be possible to disable creation of new multipath
arrays, but still to support existing ones, insert the warning, and
quote a fixed deprecation date, say, 5 years into the future?

-- 
 .''`.   martin f. krafft <madduck@d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
god is dead.
    -- nietzsche
nietzsche is dead.
    -- god
nietzsche is god.
    -- dead

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Future of md multipath

[Bodo Eggert]

martin f krafft <madduck@debian.org> wrote:
> also sprach Neil Brown <neilb@suse.de> [2009.03.05.0349 +0100]:

>> I'm in favour of deprecating it.  Whenever I hear of people using it I
>> suggest dm-multipath, but there could people I don't here about.
>> I think the upcoming mdadm-3.0 will need a compile-time option to
>> enable multipath, so people will only get it if they really really
>> want it.
> 
> How do you propose a distro to deal with this? Keep it enabled for
> a certain time (with a deprecation warning?) and then just to close
> the doors on users who still need it?

What about reverting the patch for their kernels until they release the
next major version, then drop it?

For users who compile their kernels, add "Deprecated" to the description,
and rename the CONFIG_.