From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Subject: Re: [PATCH] Disable partitions scan for multipathed devices Date: Wed, 12 Mar 2014 14:14:35 +0100 Message-ID: <53205DBB.3030100@suse.de> References: <1394624936-118530-1-git-send-email-hare@suse.de> <20140312122310.GB14017@agk-dp.fab.redhat.com> <532052CB.2090605@suse.de> <53205712.8000200@redhat.com> <53205933.5060706@suse.de> <53205AD1.40804@redhat.com> <53205BDF.2090504@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <53205BDF.2090504@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Peter Rajnoha , Alasdair Kergon , Mike Snitzer , Christoph Hellwig , dm-devel@redhat.com List-Id: dm-devel.ids 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#n= 1750) >>>> >>>> The flags are set with the dm_set_cookie libdevmapper call. >>>> >>>> The mpath already uses some bits from the "common" group and 1 flag fr= om >>>> the subsystem specific group (that is applicable only to mpath). We co= uld >>>> 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 bes= ides >>>> the kpartx call so we cover everything we need for the "host/guest" sc= enario. >>>> >>> 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=FCrnberg GF: J. Hawn, J. Guild, F. Imend=F6rffer, HRB 16746 (AG N=FCrnberg)