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