dm targets with spaces in the name

dm targets with spaces in the name

[Phillip Susi]

Is this allowed?  It looks like you can create a target with a space in 
the name, but then you can not refer to it in a rule of another target. 
  Specifically I am seeing a user with a dmraid setup with raid volumes 
using spaces in the name, and dmraid manages to create the stripe target 
( /dev/mapper/foo bar ), but then can not create the linear mapping on 
top of it for the partition, because the table looks like it has too 
many arguments due to the space.

So should you just avoid doing this, or should the kernel be fixed to 
understand quotes or backslash escapes or something to allow spaces in 
the target device file name?

Re: dm targets with spaces in the name

[Heinz Mauelshagen]

Am Mittwoch, den 03.12.2008, 12:03 -0500 schrieb Phillip Susi:
> Is this allowed?  It looks like you can create a target with a space in 
> the name, but then you can not refer to it in a rule of another target. 
>   Specifically I am seeing a user with a dmraid setup with raid volumes 
> using spaces in the name, and dmraid manages to create the stripe target 
> ( /dev/mapper/foo bar ), but then can not create the linear mapping on 
> top of it for the partition, because the table looks like it has too 
> many arguments due to the space.

What you describe here, is essentially caused by bogus names in vendor
metadata not being detected and handled properly by dmraid.

Which metadata format is that being caused by ?

Can you send me the metadata sample retrieved via "dmraid -rD"
(bzip2/tar the resulting *.{dat,offset,size} files before sending) ?

> So should you just avoid doing this,

Yes, whitespace is not to be supported in mapped device names.

> or should the kernel be fixed to 
> understand quotes or backslash escapes or something to allow spaces in 
> the target device file name?

No M$ worries, please ;)

Heinz

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

Re: dm targets with spaces in the name

[Phillip Susi]

Heinz Mauelshagen wrote:
> What you describe here, is essentially caused by bogus names in vendor
> metadata not being detected and handled properly by dmraid.
> 
> Which metadata format is that being caused by ?

isw

> Can you send me the metadata sample retrieved via "dmraid -rD"
> (bzip2/tar the resulting *.{dat,offset,size} files before sending) ?

See https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/299311

and

http://launchpadlibrarian.net/19744950/dmraid%20dump.tar.gz

Basically the user named his volume "Mother Brain 2" when he created it 
in the bios, so dmraid tries to create the target "isw_cfebfidbf_Mother 
Brain 2" which works, but then it can't use that device as the target 
for the partition linear mapping "isw_cfebfidbf_Mother Brain 21" ( that 
would be "2p1" but for some reason debian/ubuntu have a patch that 
removes the p ).

>> So should you just avoid doing this,
> 
> Yes, whitespace is not to be supported in mapped device names.

Why not?  File names with spaces in them are valid, even for dev nodes. 
  I can use dmsetup to create a device with a space in the name.  It 
seems like it should then be valid to use that device as a target in 
another one.

>> or should the kernel be fixed to 
>> understand quotes or backslash escapes or something to allow spaces in 
>> the target device file name?
> 
> No M$ worries, please ;)

Not sure what you mean there, but I actually took a look at the kernel 
code, and it was failing to parse the correct number of arguments, but 
it looks like dm_split_args() DOES understand backslash escaping.  When 
I backslash escape the spaces in the name, it appears to parse the 
correct number of arguments, yet linear_ctr() still fails with "Device 
lookup failure".

Re: Re: dm targets with spaces in the name

[Alasdair G Kergon]

I can't guarantee that names with spaces in them have had much testing
as LVM doesn't permit them.  But device-mapper itself and dmsetup
are supposed to support them.

On Thu, Dec 04, 2008 at 03:15:51PM -0500, Phillip Susi wrote:
> Not sure what you mean there, but I actually took a look at the kernel 
> code, and it was failing to parse the correct number of arguments, but 
> it looks like dm_split_args() DOES understand backslash escaping.  When 
> I backslash escape the spaces in the name, it appears to parse the 
> correct number of arguments, yet linear_ctr() still fails with "Device 
> lookup failure".
 
Tools really should not be passing path names into constructors - use the
major:minor format instead as the in-kernel code paths are much more
predictable, there are fewer opportunities for races and so it offers
better control to the userspace code.

Alasdair
-- 
agk@redhat.com

Re: dm targets with spaces in the name

[Phillip Susi]

Alasdair G Kergon wrote:
> I can't guarantee that names with spaces in them have had much testing
> as LVM doesn't permit them.  But device-mapper itself and dmsetup
> are supposed to support them.
<snip>
> Tools really should not be passing path names into constructors - use the
> major:minor format instead as the in-kernel code paths are much more
> predictable, there are fewer opportunities for races and so it offers
> better control to the userspace code.

But if you run dmsetup and key in a table referencing a device with a 
space in the name, that is what happens; linear_ctr gets passed 
"/dev/foo bar" as the path argv.  Shouldn't it then be just as capable 
of opening the device as a call to open()?

Re: Re: dm targets with spaces in the name

[Alasdair G Kergon]

On Fri, Dec 05, 2008 at 11:58:30AM -0500, Phillip Susi wrote:
> Alasdair G Kergon wrote:
> >I can't guarantee that names with spaces in them have had much testing
> >as LVM doesn't permit them.  But device-mapper itself and dmsetup
> >are supposed to support them.
> But if you run dmsetup and key in a table referencing a device with a 
> space in the name, that is what happens; linear_ctr gets passed 
> "/dev/foo bar" as the path argv.
 
which is a bug as per what I stated above, if true.

dmsetup knows nothing about the format of the table line - it's a simple
string - and should not be interfering with it: a backslash+space (after any
shell escaping) should get handled consistently, passed through to the target
and should work.

Alasdair
-- 
agk@redhat.com

Re: dm targets with spaces in the name

[Phillip Susi]

Alasdair G Kergon wrote:
> which is a bug as per what I stated above, if true.
> 
> dmsetup knows nothing about the format of the table line - it's a simple
> string - and should not be interfering with it: a backslash+space (after any
> shell escaping) should get handled consistently, passed through to the target
> and should work.

Nevermind, I must have made a typeo before because now the kernel 
accepts targets with spaces in the name just fine, as long as they are 
properly backslash escaped.

Heinz, you mentioned that dmraid should just not be using names with 
spaces in them.  My first thought was to fix dmraid to backslash escape 
the spaces, but you seem to have another idea in mind?

Re: dm targets with spaces in the name

[Arvin Schnell]

On Thu, Dec 04, 2008 at 04:52:36PM +0100, Heinz Mauelshagen wrote:
> Am Mittwoch, den 03.12.2008, 12:03 -0500 schrieb Phillip Susi:
> > Is this allowed?  It looks like you can create a target with a space in 
> > the name, but then you can not refer to it in a rule of another target. 
> >   Specifically I am seeing a user with a dmraid setup with raid volumes 
> > using spaces in the name, and dmraid manages to create the stripe target 
> > ( /dev/mapper/foo bar ), but then can not create the linear mapping on 
> > top of it for the partition, because the table looks like it has too 
> > many arguments due to the space.
> 
> What you describe here, is essentially caused by bogus names in vendor
> metadata not being detected and handled properly by dmraid.
> 
> Which metadata format is that being caused by ?
> 
> Can you send me the metadata sample retrieved via "dmraid -rD"
> (bzip2/tar the resulting *.{dat,offset,size} files before sending) ?

For some other BIOS RAID (AIC-9405 controller) you can find those
metadata in the openSUSE Bugilla:

https://bugzilla.novell.com/show_bug.cgi?id=396732#c28

Regards,
  Arvin

-- 
Arvin Schnell, <aschnell@suse.de>
Software Engineer, Research & Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

Re: Re: dm targets with spaces in the name

[Heinz Mauelshagen]

Am Montag, den 08.12.2008, 15:31 -0500 schrieb Phillip Susi:
> Alasdair G Kergon wrote:
> > which is a bug as per what I stated above, if true.
> > 
> > dmsetup knows nothing about the format of the table line - it's a simple
> > string - and should not be interfering with it: a backslash+space (after any
> > shell escaping) should get handled consistently, passed through to the target
> > and should work.
> 
> Nevermind, I must have made a typeo before because now the kernel 
> accepts targets with spaces in the name just fine, as long as they are 
> properly backslash escaped.
> 
> Heinz, you mentioned that dmraid should just not be using names with 
> spaces in them.  My first thought was to fix dmraid to backslash escape 
> the spaces, but you seem to have another idea in mind?

We don't support them in dmraid and I find them principally bogus.
Why not use '_' instead to avoid parsing hassles ?

Heinz

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

Re: Re: dm targets with spaces in the name

[Phillip Susi]

Heinz Mauelshagen wrote:
> We don't support them in dmraid and I find them principally bogus.
> Why not use '_' instead to avoid parsing hassles ?

Well I suppose you could convert spaces to underscores and the 
likelihood of a conflict with a name that originally had an underscore 
would be rather small.  Do you think that should be done in the format 
handler, or elsewhere?

Re: Re: dm targets with spaces in the name

[Heinz Mauelshagen]

Am Montag, den 15.12.2008, 11:18 -0500 schrieb Phillip Susi:
> Heinz Mauelshagen wrote:
> > We don't support them in dmraid and I find them principally bogus.
> > Why not use '_' instead to avoid parsing hassles ?
> 
> Well I suppose you could convert spaces to underscores and the 
> likelihood of a conflict with a name that originally had an underscore 
> would be rather small.  Do you think that should be done in the format 
> handler, or elsewhere?

I was thinking along the same lines.
It should be done generically in the dmraid_read() code path.

Heinz

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