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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
