On Fri, Feb 28 2014 at 9:44am -0500, Hannes Reinecke <hare@xxxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
