FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 05-09-2012, 11:04 PM
Chandra Seetharaman
 
Default dm mpath: add ability to disable partition creation

Reviewed-by: Chandra Seetharaman <sekharan@us.ibm.com>


On Tue, 2012-05-08 at 17:56 -0400, Mike Snitzer wrote:
> From: Hannes Reinecke <hare@suse.de>
>
> When multipath devices are being used as disks for VM Guests any
> partition scanning / setup should be done within the VM Guest, not from
> host. So we need to a mechanism to switch off partition scanning and
> creation via kpartx.
>
> The new 'no_partitions' feature serves as a notifier to kpartx to _not_
> create partitions on these multipath devices.
>
> Signed-off-by: Hannes Reinecke <hare@suse.de>
> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
> ---
> drivers/md/dm-mpath.c | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
> index 0fc6849..1039e7f 100644
> --- a/drivers/md/dm-mpath.c
> +++ b/drivers/md/dm-mpath.c
> @@ -85,6 +85,7 @@ struct multipath {
> unsigned queue_if_no_path:1; /* Queue I/O if last path fails? */
> unsigned saved_queue_if_no_path:1; /* Saved state during suspension */
> unsigned use_default_hw_handler:1; /* Use attached device handler */
> + unsigned no_partitions:1; /* Avoid partition scanning */
>
> unsigned pg_init_retries; /* Number of times to retry pg_init */
> unsigned pg_init_count; /* Number of times pg_init called */
> @@ -770,7 +771,7 @@ static int parse_features(struct dm_arg_set *as, struct multipath *m)
> const char *arg_name;
>
> static struct dm_arg _args[] = {
> - {0, 6, "invalid number of feature args"},
> + {0, 7, "invalid number of feature args"},
> {1, 50, "pg_init_retries must be between 1 and 50"},
> {0, 60000, "pg_init_delay_msecs must be between 0 and 60000"},
> };
> @@ -796,6 +797,11 @@ static int parse_features(struct dm_arg_set *as, struct multipath *m)
> continue;
> }
>
> + if (!strcasecmp(arg_name, "no_partitions")) {
> + m->no_partitions = 1;
> + continue;
> + }
> +
> if (!strcasecmp(arg_name, "pg_init_retries") &&
> (argc >= 1)) {
> r = dm_read_arg(_args + 1, as, &m->pg_init_retries, &ti->error);
> @@ -1380,7 +1386,8 @@ static int multipath_status(struct dm_target *ti, status_type_t type,
> DMEMIT("%u ", m->queue_if_no_path +
> (m->pg_init_retries > 0) * 2 +
> (m->pg_init_delay_msecs != DM_PG_INIT_DELAY_DEFAULT) * 2 +
> - m->use_default_hw_handler);
> + m->use_default_hw_handler +
> + m->no_partitions);
> if (m->queue_if_no_path)
> DMEMIT("queue_if_no_path ");
> if (m->pg_init_retries)
> @@ -1389,6 +1396,8 @@ static int multipath_status(struct dm_target *ti, status_type_t type,
> DMEMIT("pg_init_delay_msecs %u ", m->pg_init_delay_msecs);
> if (m->use_default_hw_handler)
> DMEMIT("default_hw_handler ");
> + if (m->no_partitions)
> + DMEMIT("no_partitions ");
> }
>
> if (!m->hw_handler_name || type == STATUSTYPE_INFO)


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 07-25-2012, 12:02 PM
Hannes Reinecke
 
Default dm mpath: add ability to disable partition creation

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)


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 07-27-2012, 02:00 PM
Hannes Reinecke
 
Default dm mpath: add ability to disable partition creation

On 07/26/2012 07:03 PM, Benjamin Marzinski wrote:
> On Wed, Jul 25, 2012 at 02:02:15PM +0200, Hannes Reinecke wrote:
[ .. ]
>> 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.
>
> Kpartx does already grab the dm device name, uuid and target type
> (although it doesn't currently use the target type for anything). So,
> aside from adding code to read a config file, we don't really have to
> add any complexity to be able to have kpartx configure a device based on
> dm name (which admittedly probably isn't that useful), dm UUID, or
> target type. We could also have it configure based on the blkid
> results, which should be present when it's called by udev. When
> called manually, kpartx could use libblkid.
>
Hmpf. Feels like a waste; multipath already has this information ...
Anyway.

> We do lose the ability to have kpartx easily configure a device based on
> hardware type. However, that's not really essential. Multipath needs
> it because it can't even finish setting up a device until it knows the
> hardware type. For kpartx, it could make configuration simpler in cases
> where all of the LUNs from a particular hardware type needed to be
> configured the same way. This may be handy, but its not necessary, and
> you could achieve the same results using UUIDs. What we gain is the
> ability to set this property for non-multipath devices, which currently
> isn't possible. Also, blkid based (fs type, fs uuid, and fs label)
> configuration seems to me like it would be the most useful.
>
Oh. Right.
Yes, indeed, other target types beside from multipath will benefit
from this approach, too.

> Now I'm not arguing that adding configuration file handling isn't adding
> complexity, and adding libblkid calls would add more. But since
> multipath always sets the UUID, I don't see this losing any reliability,
> and I does gain the fexibility to work with any dm target type. I
> don't feel strongly about this one way or the other, but do see the
> benefits of having kpartx own this configuration setting.
>
The main problem I have with the kpartx approach is that none of the
information in the device-mapper device is well-defined.
The name certainly isn't, and even the UUID is a case of "let's hope
no-one else is daft enough using this".

Did we ever get around formalizing how the UUID should look like?
If so, and if we could enforce this policy, then we can be sure the
UUID is actually meaningful.

But if we can't then kpartx would have to crawl back to the parent
device to grab some information from there.
blkid notwithstanding.
And that's just horrible.

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)


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 08:15 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org