linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Phillip Susi <psusi@ubuntu.com>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] libdevmapper's handling of devices with spaces in the name
Date: Wed, 26 Feb 2014 20:12:42 +0100	[thread overview]
Message-ID: <530E3CAA.1070308@redhat.com> (raw)
In-Reply-To: <530E3464.3050606@ubuntu.com>

Dne 26.2.2014 19:37, Phillip Susi napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/26/2014 1:21 PM, Zdenek Kabelac wrote:
>> This is no longer true for 'modern' systems with udev.
>>
>> libdevmapper no longer creates any /dev nodes - it's all job for
>> udev.
>>
>> And udev has had in dark ages the idea to use 'space' as a
>> separator for device names in device list. Thus it 'invented'
>> escaping/mangling names. (There are more prohibited characters
>> which used to be used for normal device names (see man dmsetup
>> mangling))
>>
>> If you have system without udev - you could disable name mangling
>> on i.e. dmsetup cmdline.
>
> So it is doing this to try and work around a bug in udev.  Has this
> been fixed in modern udev and should be safe to disable?  It doesn't

Unfortunately this is seen as a 'feature' of udev - so there is no plan to fix 
it in udev - since too many other things depends on the current naming logic 
(i.e all udev rules scripts written in bash would need major fixes to work 
with characters which are nontrivil to work with)
All surrounding Gnome above it as well - you would be really amazed if you 
would check this deeply...


> seem to work for me when I do with udev 204: I end up with
> /dev/mapper/foo.
>
>> There is also envvar DM_DEFAULT_NAME_MANGLING_MODE_ENV_VAR_NAME
>> which could be used to set prefered behavior.
>>
>> So there is no bug in libdm side - but I'll not comment on the
>> rest...
>
> The bug in libdm is that it is lieing to the calling application about
> the name of the device, claiming it is not escaped, when in fact, it
> is.  Or is dm_task_get_name() supposed to return a human readable
> string rather than the actual file name?  If that is the case, how to
> get the actual file name instead?

As said - there is no bug in libdm - libdm expects udev to create nodes.
You can reconfigure libdm to do this job instead of udev - but then nothing 
else will work with it - so it's basically dead-road...

The best you can do is to not use names which needs mangling - that's my best 
suggestions (and lvm team already spend countless hours on some usable 
workarounds and solutions...)

For mangling see 'dmsetup mangle' help - how to obtain device names...

Zdenek

  reply	other threads:[~2014-02-26 19:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 17:04 [linux-lvm] libdevmapper's handling of devices with spaces in the name Phillip Susi
2014-02-26 18:21 ` Zdenek Kabelac
2014-02-26 18:37   ` Phillip Susi
2014-02-26 19:12     ` Zdenek Kabelac [this message]
2014-02-26 20:52       ` Phillip Susi
2014-02-26 21:40         ` Zdenek Kabelac
2014-02-26 22:17           ` Phillip Susi
2014-02-26 23:26             ` Alasdair G Kergon
2014-02-27  8:51             ` Peter Rajnoha
2014-02-27  9:08             ` Peter Rajnoha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530E3CAA.1070308@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=psusi@ubuntu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).