On Tue, Jul 26 2016 at 2:02am -0400,
Hannes Reinecke <hare@xxxxxxx> wrote:
> On 07/25/2016 07:53 PM, Mike Snitzer wrote:
> >
> >The various ioctls you're seeing is just multipathd responding to the
> >failures. Part of reloading a table (with revised path info, etc) is to
> >suspend and then resume the device that is being updated.
> >
> >But I'm not actually sure on the historic reasoning of why
> >queue_if_no_path is disabled (and active setting saved) on suspend.
> >
> >I'll think about this further but maybe others recall why?
> >
> Yes, originally multipath was using the device-mapper internal
> queueing mechanism, which meant that queued I/O was holding a
> reference to the table. So you couldn't change the table while I/O
> was pending/queued, and you'd have to unset queue_if_no_path to
> allow the tables to be swapped.
> (Or something. That's the reasoning I gave to myself when seeing
> that construct. And I found myself pretty convincing. Not that I've
> ever tested that.)
> So with commit e809917735ebf ("dm mpath: push back requests instead of
> queueing") that obviously isn't true anymore, and I'd love to see that
> quirk go.
Yeah, but unfortunately (or fortunately?) I've reinstated bio-based
multipath support -- for current 4.8 merge -- that actually _does_ make
use of (and reintroduces) the multipath target's internal queueing only
for bio-based use, see:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.8&id=76e33fe4e2c4363c2b9f627472bd43dc235c3406
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
