As a mulitpath developer, I find that multipath is getting bigger
and harder to maintain now, and I'm really looking forward to this
change, and I hope to be able to devote myself to this change too.
I am very interested in any news of the multipath redesign and
hope to see results soon.
I can't imagine what the new multipath looks like, but I suggest
some bad places for the current multipath we should avoid:
1) coarse grained lock;
2) vectors;
3) waiter thread;
4) high coupling;
5) too many configurations;
I really hope we can make a clean, efficient and easy to use
multipath.
Thank you
Tang Junhui
发件人: Hannes Reinecke <hare@xxxxxxx>
收件人: Mike Snitzer <snitzer@xxxxxxxxxx>,
抄送: "linux-block@xxxxxxxxxxxxxxx" <linux-block@xxxxxxxxxxxxxxx>, "lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx" <lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx>, device-mapper development <dm-devel@xxxxxxxxxx>, "linux-scsi@xxxxxxxxxxxxxxx" <Linux-scsi@xxxxxxxxxxxxxxx>
日期: 2017/01/14 01:52
主题: Re: [dm-devel] [LSF/MM TOPIC][LSF/MM ATTEND] multipath redesign
发件人: dm-devel-bounces@xxxxxxxxxx
On 01/13/2017 05:07 PM, Mike Snitzer wrote:
> On Fri, Jan 13 2017 at 10:56am -0500,
> Hannes Reinecke <hare@xxxxxxx> wrote:
>
>> On 01/12/2017 06:29 PM, Benjamin Marzinski wrote:
[ .. ]
>>> While I've daydreamed of rewriting the multipath tools multiple times,
>>> and having nothing aginst you doing it in concept, I would be happier
>>> knowing that it won't simply mean that there are two sets of tools, that
>>> both need to be supported to deal with all customer configurations.
>>>
>> Sure. I feel the pain of supporting multipath-tools all too strongly.
>> Having two tools for the same thing is always a pain, and I would like
>> to avoid this if at all possible.
>
> I welcome your work. Should help us focus on what fat needs to be
> trimmed from both multipath-tools and kernel.
>
> Might be a good time to branch multipath-tools and get very aggressive
> with trimming stuff that is outdated.
>
> Things like the event stuff, using select interface, that Andy Grover is
> working on (and Mikulas is taking a stab at finishing/optimizing) is
> something that might help... but your approach described in this thread
> may prove better.
>
> Point is, everything should be on the table for revitalizing multipath
> userspace (and kernel) to meet new requirements (e.g. NVMEoF, etc).
>
> And yes, I'd prefer to ultimately see these advances land in terms of DM
> multipath advances but we'll take it as it comes.
I'm fully on board with that.
And it would be good if Ben Marzinski would be present, too;
he might have some insights which both of us might lack
(like the ominous dm-event interface into multipathd where we both
struggle to figure out what it's for ...)
Looking forward to that discussion.
And promising to have some results by then.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
