Re: [PATCH] Disable partitions scan for multipathed devices

[Hannes Reinecke <hare@suse.de>]

On 03/12/2014 02:06 PM, Peter Rajnoha wrote:
> 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
> 
Ah. Missed them. Will be including those.

_However_: The 'no_partition' feature has the advantage that you
don't need to modify the multipath code; it'll just take whatever is
in 'features' and pass it 1:1 into the device-mapper table.

When using cookies for that we'd need either a separate
mechanism/flag for multipathing or filter out the features list.
_And_ we need to modify libdevmapper _and_ multipath at the same
time to make that work.
But if you insist ...

So can you make a patch for libdevmapper to add this cookie flag?
I'll be checking the multipath-tools code ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)