On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote:
> Guido Günther <agx@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.
> 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.
Cheers,
-- Guido