[dm-devel] dm-mpath: always return reservation conflict
Christoph Hellwig
hch at infradead.org
Mon Sep 26 16:52:30 UTC 2016
Getting back to this after Hannes recovered from his vacation
and I had a chat with him..
On Mon, Aug 15, 2016 at 09:40:39AM -0400, Mike Snitzer wrote:
> Seems we still need a more sophisticated approach. But I'm left
> wondering: if we didn't do it would anything notice? Sadly, the same
> big question from the original thread from a year ago:
Yes. I have a customer looking to push the pNFS SCSI layout into
a product, and the major show stopper right now is that we can
trivially get into failver loops without this (or and equivalent)
fix.
A year ago SCSI layout was still work in progress in the IETF,
people use the similar block layout instead that doesn't use
PRs and we also didn't have the in-kernel PR API, so you effectively
couldn't use PRs with multipathing.
> https://patchwork.kernel.org/patch/6797111/
>
> > So this is throw-away for now (and I'll get Hannes' patch applied for
> > 4.8-rc3, with the tweak of returning -EBADE immediately):
>
> Unfortunately, I'm _not_ staging Hannes' patch until I have James
> Bottomley's Ack (given his original issues with the patch haven't been
> explained away AFAICT).
I've added James to the Cc. His argument was that the old behavior
could be implemented to use some non-standard use of reservations
without a specific example. I don't really think his example even
is practical - once we use dm-mpath it exclusively claims the underling
block devices, so any sort of selective reservations would have had
to happen before even starting dm-multipath. So a dynamic SAN
controller would have to tear down and rebuild the dm-multipath setup
at all the time.
More information about the dm-devel
mailing list