[dm-devel] [PATCH 8/8] dm-mpath: do not activate failed paths
Mike Snitzer
snitzer at redhat.com
Fri Feb 28 15:02:43 UTC 2014
On Fri, Feb 28 2014 at 9:44am -0500,
Hannes Reinecke <hare at suse.de> wrote:
> On 02/28/2014 03:22 PM, Mike Snitzer wrote:
> [ .. ]
> >
> > FYI, I still intend to review/take your "accept failed paths" patch.
> > Would be helpful if any rebase is needed for that patch that you do so
> > and re-post.
> >
> > One thing I noticed is you're only converting MAJ:MIN paths to devices.
> > I think we should factor a helper out of DM core that does the full path
> > lookup check from dm_get_device() -- rather than you open coding an
> > older version of the MAJ:MIN device path processing.
> >
> > But is there a reason for not using lookup_bdev()? Because the device
> > is failed it cannot be found using lookup_bdev()?
> >
> Yes, that's precisely it.
> When setting dev_loss_tmo very aggressively (to, say, 10 or even 5
> seconds) it might well be that multipathd won't be able to keep up
> with the events in time.
> So by the time multipathd tries to push a new table into the kernel
> (which contains major:minor numbers only) those devices are already
> gone. So lookup_bdev() won't be able to find them, either.
Been talking this over with Alasdair. Need some things clarified.
Are you needing to handle non-existent devices during initial mpath
table load?
Or is the failed path in question already part of the active mpath table
-- so active table currently holds a reference to the device?
Or do you need to support both cases? Sounds like you want to support
both cases..
> Not sure if factoring things out from dm_get_device() would help
> here ...
>
> But I'll be sending an updated patch, which'll apply on top of the
> 'push back' patchset.
Thanks.
More information about the dm-devel
mailing list