Re: [PATCH 0/2] dm: alternate solution to reloading with failed paths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 15, 2014 at 05:44:53PM -0400, Mike Snitzer wrote:
> On Wed, Aug 13 2014 at  2:53pm -0400,
> Benjamin Marzinski <bmarzins@xxxxxxxxxx> wrote:
> 
> > This is different solution to the problem of multipath not being able to
> > reload devices with failed paths than the one that Hannes first proposed.
> > It adds a list of dm_devs to the mapped_device structure.  All of the table
> > lists point to devices on this list. The list keeps track of how many tables
> > are accessing these devices, and locks them to deal with tables being created
> > and destroyed at the same time.  This avoids the issue of having tables that
> > list devices for which the kernel is not holding any reference, and which
> > can disappear and come back as a completely different device if userspace
> > drops its reference.  This also allows these devices to be reinstated without
> > another table reload.
> > 
> > The other patch deals with issues I discovered while tracking down why
> > multipath devices with no valid paths would hang on table reload. It turns
> > out that multipath_map can no longer be called after a table reload until
> > queue_io is cleared, but multipath map was previously the function that
> > usually cleared queue_io.
> 
> I've done a first pass review of the code changes and overlayed a
> cleanup patch in this branch:
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=devel
> 
> I'll do another pass of review tomorrow and perform a full regression
> test as well as a targetted test of loading various multipath tables
> with no devices.
> 
> If all looks good I'll get it staged for 3.18.


You changes look fine by me.

-Ben

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux