UUID in fstab for device mapper devices?

[Ferenc Wagner]

Guido Günther <agx at sigxcpu.org> writes:

> On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote:
>
>> Guido Günther <agx at sigxcpu.org> writes:
>> 
>>> On Fri, Aug 07, 2009 at 04:28:46PM +0200, Max Vozeler wrote:
>>> 
>>>> we recently changed d-i (partman-target, to be precise) to use 
>>>> UUIDs in fstab in order to get stable device naming. [...]
>>>> Since then, we concluded that it is preferable to go back to plain
>>>> /dev/mapper/ paths for LVM LVs because those already provide stable 
>>>> device naming (and are more descriptive).
>> 
>> And filesystem UUIDs are pretty useless as soon as you start using LVM
>> snapshots, dd backups or multipath for example.
>> 
>>> ENV{DM_UUID}=="mpath-*", \
>>> 	SYMLINK+="disk/by-id/$env{DM_TYPE}-$env{DM_NAME}"
>>> [...]
>>>
>>> This is what should idealy be used in d-i for multipath device naming.
>>> We could then start to remove the hacks that use /dev/mapper/mpath* to
>>> reference multipath devices then.
>> 
>> My limited experience shows that multipath uses unique /dev/mapper/<WWID>
>> device names by default, or the configured name, as Bastian mentioned.
>> Is that because I'm lucky, and other types of multipaths don't behave
>> so nice?  Also, I haven't seen mpath-names apart from an obscure
>> multipath.conf option...
>
> It uses the WWID, the configured name (via multipath.conf) or mpathX if
> you set user_friendly_names=yes - which we currently use in d-i to have
> an easy way to identify multipath devices.

OK, so the problem is identifying multipath devices in d-i.  So that
option would be better called d-i_friendly_names, because from the
user PoV losing name persistence -- which this option implies --,
isn't friendly or useful, in my opinion.  If only multipath used
mpath-WWID by default, running these circles around udev and by-id
would be unnecessary.  Or if d-i used another way to find
multipath devices, like for example:

echo "show maps" | multipathd -k | sed '1d;s/ .*//'

Is doing something like that out of question?  Changing the default
naming scheme may be too dangerous (altough I'm all for it :), but
getting rid of "user_friendly_names" would restore the general
persistence of device-mapper names.

>> Anyway, an unfortunate multipath/LVM interaction should also be
>> considered: without special configuration in lvm.conf, the PV scan
>> finds the LVM metadata on the individual paths as well as on the
>> multipath device, then tries to create mappings straight onto the
>> first path, skipping the multipath layer.  Of course it fails, because
>> that device isn't available any more, but the error is rather hard to
>> diagnose from the initramfs prompt.
>
> This can be fixed by preferring /dev/mapper/mpathX names.

Yes, but LVM does not prefer those currently, so the installed system
won't boot without further tweaking in such cases.  I just wanted to
make sure this problem won't be overlooked.
-- 
Thanks,
Feri.