[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140314092519.GA10139@infradead.org>
Date: Fri, 14 Mar 2014 02:25:19 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Mike Snitzer <snitzer@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Hannes Reinecke <hare@...e.de>, Jeff Moyer <jmoyer@...hat.com>,
Jens Axboe <axboe@...nel.dk>, Shaohua Li <shli@...ionio.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] block: rework flush sequencing for blk-mq
On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
> Pretty ironic that in the same email that you ask someone to "Let's make
> this a little less personal." you start by asserting upstream
> dm-multipath sees very little testing -- and use your commit that
> recently broke dm-multipath as the basis. Anyway, please exapnd on what
> you feel is broken with upstream dm-multipath.
Getting a little upset, eh? I didn't say it's broken, I said it gets
very little testing. The regression from me was found like so many
before only after it was backported o some enterprise kernel.
I think the problem here is two-fold:
a) the hardware you use with dm-multipath isn't widely available.
b) it uses a very special code path in the block layer no one else uses
a) might be fixable by having some RDAC or similar emulation in qemu if
someone wants to spend the effort.
b) is a bit harder, but we should think hard about it when rewriting the
multipath code to support blk-mq. Talking about which I think trying to
use dm-multipath on any blk-mq device will go horribly crash and boom at
the moment.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists