Re: [dm-devel] [RESEND PATCH 3/3] dm mpath: add ability to disable partition creation

From: Hannes Reinecke <hare@suse.de>
To: device-mapper development <dm-devel@redhat.com>,
	James Bottomley <jbottomley@parallels.com>,
	linux-scsi@vger.kernel.org, Peter Rajnoha <prajnoha@redhat.com>,
	Benjamin Marzinski <bmarzins@redhat.com>
Subject: Re: [dm-devel] [RESEND PATCH 3/3] dm mpath: add ability to disable partition creation
Date: Wed, 25 Jul 2012 14:02:15 +0200	[thread overview]
Message-ID: <500FE047.8060009@suse.de> (raw)
In-Reply-To: <20120711151839.GC2095@agk-dp.fab.redhat.com>

On 07/11/2012 05:18 PM, Alasdair G Kergon wrote:
> On Tue, Jun 26, 2012 at 02:32:05PM -0400, Mike Snitzer wrote:
>> The new 'no_partitions' feature serves as a notifier to kpartx to _not_
>> create partitions on these multipath devices.
>  
> This isn't really multipath-specific so doesn't belong in the target.
> It could go into dm core, but we already have flags attached to
> udev cookies that can turn udev rules on and off and thereby could
> allow userspace multipath to control whether or not kpartx creates
> partitions on any particular device.
> 
> But first I'd like us to explore creating a config file for kpartx and
> controlling the behaviour from there.  Activation could then be
> triggered by target type, device name, scsi WWID, dm UUID etc. according
> to rules in that file.
> 
But that would mean one would have to maintain _two_ configuration
files, one for multipath and one for kpartx.

Also kpartx initially doesn't have any clue about device names, SCSI
WWIDs etc. It just takes a device-mapper device and acts upon it.
The only information it's got is the device-mapper name (which could
be anything) and the device-mapper UUID if present.

Same goes for udev rules; one would have to traverse the device
stack backwards to retrieve any information about the hardware.

So when moving the configuration into kpartx we would lose quite
some flexibility. And reliability, methinks.

Flexilibity is a valid goal, but not when it can achieved only by
adding complexity to other pieces.

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)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html