On Mon, Nov 19 2018 at 4:39am -0500, Christoph Hellwig <hch@xxxxxx> wrote: > On Fri, Nov 16, 2018 at 02:28:02PM -0500, Mike Snitzer wrote: > > You rejected the idea of allowing fine-grained control over whether > > native NVMe multipathing is enabled or not on a per-namespace basis. > > All we have is the coarse-grained nvme_core.multipath=N knob. Now > > you're forecasting removing even that. Please don't do that. > > The whole point is that this hook was intended as a band aid for the > hypothetical pre-existing setups. Not ever for new development. It pains me that you're marching us towards increased conflict that needs resolution through more formal means. And that now I'm going to have to document the timeline of your authoritarian approach to stifling another Linux maintainer's freedom to do his job of delivering on functionality I've been depended on for many years. > > Please, PLEASE take v2 of this patch.. please? ;) > > See the previous mail for the plan ahead. I'm sick and tired of you > trying to sneak your new developemts back in. I've only ever posted patches in the open and never has it been with the idea of sneaking anything in. Miscategorizing my actions as such is a gross abuse that I will not tolerate. If we were to confine ourselves to this v2 patch I pleaded with you to take: https://lkml.org/lkml/2018/11/17/4 1) Hannes proposed a simplistic patch that didn't account for the fact that NVMe's ana workqueue wouldn't get kicked, his intent was to make ANA work independent of your native multipathing. (The fact he or I even need to post such patches, to unwind your tight-coupling of ANA and multipathing, speaks to how you've calculatingly undermined any effort to implement proper NVMe multipathing outside of the NVMe driver) 2) ANA and multipathing are completely disjoint on an NVMe spec level. You know this. SO: will you be taking my v2 patch for 4.21 or not? Please advise, thanks. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
