<tt>Hello Hannes:</tt> 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@suse.de> 收件人: Mike Snitzer <snitzer@redhat.com>, 抄送: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>, "lsf-pc@lists.linux-foundation.org" <lsf-pc@lists.linux-foundation.org>, device-mapper development <dm-devel@redhat.com>, "linux-scsi@vger.kernel.org" <Linux-scsi@vger.kernel.org> 日期: 2017/01/14 01:52 主题: Re: [dm-devel] [LSF/MM TOPIC][LSF/MM ATTEND] multipath redesign 发件人: dm-devel-bounces@redhat.com <hr noshade> <tt>On 01/13/2017 05:07 PM, Mike Snitzer wrote: > On Fri, Jan 13 2017 at 10:56am -0500, > Hannes Reinecke <hare@suse.de> 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@suse.de +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@redhat.com </tt><a href="https://www.redhat.com/mailman/listinfo/dm-devel"><tt>https://www.redhat.com/mailman/listinfo/dm-devel</tt></a><tt> </tt>