[dm-devel] [PATCH] Disable partitions scan for multipathed devices

[Peter Rajnoha]

On 03/12/2014 02:02 PM, Peter Rajnoha wrote:
> On 03/12/2014 01:55 PM, Hannes Reinecke wrote:
>> On 03/12/2014 01:46 PM, Peter Rajnoha wrote:
>>> On 03/12/2014 01:27 PM, Hannes Reinecke wrote:
>>>> On 03/12/2014 01:23 PM, Alasdair G Kergon wrote:
>>>>> On Wed, Mar 12, 2014 at 12:48:56PM +0100, Hannes Reinecke wrote:
>>>>>> For this I've implemented a new feature 'no_partitions' which
>>>>>> just serves as a notifier to kpartx to _not_ create partitions
>>>>>> on these devices.
>>>>>  
>>>>> This should be covered by the existing cookie flags (which udev rules
>>>>> already use, if you're using udev).  It's not a multipath-specific
>>>>> problem but can apply to other targets too.
>>>>>
>>>> Ah.
>>>>
>>>> How? To my knowledge the 'cookies' mechanism is to enable
>>>> libdevmapper to wait until udev is done with device creation.
>>>>
>>>
>>> Thing with calling kpartx in udev is that it's only used for mpath
>>> devices at the moment, not for all dm devices in general. We could
>>> add a hook to call kpartx for each dm device, not just limiting it
>>> to the mpath, but there has been no call for this yet...
>>>
>>> As for the flags encoded in the cookie - the cookie has two parts -
>>> the lower 16 bits are used for synchronization identifier, the
>>> higher 16 bits are used for passing flags. Out of these 16 'flag bits',
>>> 8 bits are common for all DM devices and they're meant to be used for
>>> flagging DM devices in general and the rest 8 bits are meant to be used
>>> for specific DM subsystem use (see also
>>> https://git.fedorahosted.org/cgit/lvm2.git/tree/libdm/libdevmapper.h#n1750)
>>>
>>> The flags are set with the dm_set_cookie libdevmapper call.
>>>
>>> The mpath already uses some bits from the "common" group and 1 flag from
>>> the subsystem specific group (that is applicable only to mpath). We could
>>> check if there's a combination we could reuse, but I think that in this
>>> case we should just introduce a new mpath subsystem specific flag that
>>> would direct udev rules to skip the kpartx call.
>>>
>>> Now the question is whether there is anything else we need to skip besides
>>> the kpartx call so we cover everything we need for the "host/guest" scenario.
>>>
>> The only other problem I could think of is the ominous 'blkid' call
>> problem.
>>
>> Currently 'blkid' is run for every 'change' event,
>> And multipath is very keen on generating 'change' events under a
>> variety of situations, _plus_ there is the in-kernel
>> 'PATH_FAILED/PATH_REINSTATED' mechanism.
>> Each of which (except PATH_FAILED) will cause 'blkid' to be run
>> by virtue of 13-dm-disk.rules.
>> (Actually, someone should expand that to cover 'PATH_REINSTATED', too)
>>
>> So when that multipath device happens to have no dependencies left
>> or all of those are failed, 'blkid' will hang until the device
>> becomes useable again.
> 
> This should be covered by latest changes in multipath - I revisited
> this a month ago with Ben and we've introduced some new udev rules
> to avoid running blkid in case we've run out of paths (there's a new
> 11-dm-mpath.rules). Though it's not yet upstream, but it has already
> been proposed on this list (we did this for RHEL originally to solve
> some problems we've been running into).
> 
> So this is already resolved, I hope.
> 

https://www.redhat.com/archives/dm-devel/2014-February/msg00075.html
https://www.redhat.com/archives/dm-devel/2014-February/msg00076.html
https://www.redhat.com/archives/dm-devel/2014-February/msg00074.html

-- 
Peter