lkml.org 
[lkml]   [2018]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/3] Provide more fine grained control over multipathing
From
Date
On 5/29/18 5:27 PM, Mike Snitzer wrote:
> On Tue, May 29 2018 at 4:09am -0400,
> Christoph Hellwig <hch@lst.de> wrote:
>
>> On Tue, May 29, 2018 at 09:22:40AM +0200, Johannes Thumshirn wrote:
>>> For a "Plan B" we can still use the global knob that's already in
>>> place (even if this reminds me so much about scsi-mq which at least we
>>> haven't turned on in fear of performance regressions).
>>>
>>> Let's drop the discussion here, I don't think it leads to something
>>> else than flamewars.
>>
>> If our plan A doesn't work we can go back to these patches. For now
>> I'd rather have everyone spend their time on making Plan A work then
>> preparing for contingencies. Nothing prevents anyone from using these
>> patches already out there if they really want to, but I'd recommend
>> people are very careful about doing so as you'll lock yourself into
>> a long-term maintainance burden.
>
> Restating (for others): this patchset really isn't about contingencies.
> It is about choice.
>
> Since we're at an impasse, in the hopes of soliciting definitive
> feedback from Jens and Linus, I'm going to attempt to reset the
> discussion for their entry.
>
> In summary, we have a classic example of a maintainer stalemate here:
> 1) Christoph, as NVMe co-maintainer, doesn't want to allow native NVMe
> multipath to actively coexist with dm-multipath's NVMe support on the
> same host.
> 2) I, as DM maintainer, would like to offer this flexibility to users --
> by giving them opt-in choice to continue using existing dm-multipath
> with NVMe. (also, both Red Hat and SUSE would like to offer this).
>
> There is no technical reason why they cannot coexist. Hence this simple
> patchset that was originally offered by Johannes Thumshirn with
> contributions from myself.

Here's what I think - flag days tend to suck. They may be more convenient
for developers, but they inflict pain on users. Sometimes they prevent
them from moving forward, since updates are now gated on external
dependencies. Moving forward with a new architecture is great, but
proper care has to be given to existing users of multipath, regardless
of how few they may be.

This patchset seems pretty clean and minimalist. Realistically, I'm
guessing that SUSE and RH will ship it regardless of upstream status.

--
Jens Axboe

\
 
 \ /
  Last update: 2018-05-30 21:06    [W:0.326 / U:27.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site