Guido Günther <a...@sigxcpu.org> writes: > On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote: > >> Guido Günther <a...@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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org