Future of md multipath
Christoph Hellwig
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Neil Brown
> 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
martin f krafft
> 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
Neil Brown
> also sprach Neil Brown <ne...@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..
martin f krafft
> > 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
Bodo Eggert
> also sprach Neil Brown <ne...@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_.