Re: [PATCH 4/6] libmultipath: Fixup 'DM_DEVICE_RELOAD' handling

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

 



On 05/06/2016 10:12 PM, Benjamin Marzinski wrote:
> On Wed, May 04, 2016 at 07:57:28AM +0200, Hannes Reinecke wrote:
>> libdevmapper has the 'quirk' that DM_DEVICE_CREATE is translated
>> internally into a create/load/resume sequence, and the associated
>> cookie will wait for the last 'resume' to complete.
>> However, DM_DEVICE_RELOAD has no such translation, so if there
>> is a cookie assigned to it the caller _cannot_ wait for it,
>> as the cookie will only ever be completed upon the next
>> DM_DEVICE_RESUME.
>> multipathd already has some provisions for that (but even there
>> the cookie handling is dodgy), but 'multipath -r' doesn't know
>> about this.
>> So to avoid any future irritations this patch updates the
>> dm_addmad_reload() call to handle the cookie correctly,
>> and removes the special handling from multipathd.
> 
> I don't see what's multipathd specific about any of the handling here.
> The real answer is that device-mapper does nothing with cookies on
> table reload. We should never be calling dm_task_set_cookie() for 
> dm_addmap(DM_DEVICE_RELOAD, ...) calls in the first place. We end up
> creating a cookie, decrementing the cookie, incrementing the cookie, and
> finally waiting on it, when we could just be creating a cookie and then
> waiting on it.
> 
> It's kind of hard to find an easy to show example of this breaking. You
> would need to have the dm_addmap() command fail with some other error than
> EROFS.  If that happens, the dm_simplecmd() call will never happen, and
> there will be a cookie sitting around on the system.  If we never added
> a cookie to the task in dm_addmap(DM_DEVICE_RELOAD, ...), then there
> wouldn't be this cookie sitting around.
> 
But then ... how is this supposed to work?
Are we supposed to call DM_DEVICE_RESUME even after DM_DEVICE_RELOAD
failed?
None of the other callers do that ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@xxxxxxx			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

--
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