disk/by-uuid/foo symlink points to snapshot rather than the origin

[Soren Hansen]

Binary package hint: lvm2

Heard in #ubuntu-server:

On a hardy system, if you create an lvm snapshot, the snapshot and the origin obviously have the same UUID. If you reboot, the symlink in /dev/disk/by-uuid/ points to the snapshot rather than the origin.

/etc/udev/rules.d/65-dmsetup.rules does seem to have code to handle this, but it apparantly does not work as intended.

I'm attaching a collection of debug info (all I could think of asking the user for).

[Scott James Remnant (Canonical) (canonical-scott)]

This is by design, the code in 65-dmsetup.rules is deliberately making the snapshot origin the *LOWEST* possible priority.

If you want that changed, I'll need a signed statement from Kees in his own blood that he agrees with you <g>

[Kees Cook (kees)]

Since there are multiple snapshots possible per single LV origin, the UUID symlinks would become either non-deterministic or operate on a last-come-first-served basis. Having the symlink move around each time a snapshot is created is asking for trouble. Instead, UUID should always point to the "real" filesystem, since there is only one of those.

[Kees Cook (kees)]

Though I think I just argued changing the behavior. I'm going to go do some research, I swear there was a really good reason for this...

[Kees Cook (kees)]

History for this is based on bug 117225. Note that the problem was with /dev/mapper entries, not /dev/disk/by-uuid entries. Perhaps the /dev/disk/by-uuid issue is a side-effect of this? (I don't use FS UUIDs for mounting since /dev/mapper names are already good enough.) I would be fine with /dev/disk/by-uuid always pointing to the origin -- it makes sense, as detailed in comment 3.

Associated changelogs:

devmapper (2:1.02.18-1ubuntu4) gutsy; urgency=low

  * Fix a regression introduced by Kees's otherwise largely correct patch.
    We still need to not run vol_id on snapshot target devices, otherwise
    we'll end up using a changing device, and arguing over UUID/LABEL
    symlinks. (This might not be a complete fix, LVM may need to be patched
    to make inactive devices).

  * Correct a school-boy error with the stat()/mknod() loop; we can't unlink
    then mknod() since that means there's a period without a device node,
    which could upset callers. Instead rename() the new device node over
    the top.

 -- Scott James Remnant <email address hidden> Tue, 29 May 2007 09:40:24 +0100

devmapper (2:1.02.18-1ubuntu3) gutsy; urgency=low

  * Adjust debian/dmsetup.udev rule to not ignore "snapshot" devices. This
    will be needed even after "udev-lvm-mdadm-evms-gutsy" is solved (LP:
    #117225).
  * Update Maintainer fields for Ubuntu.

 -- Kees Cook <email address hidden> Sun, 27 May 2007 12:12:22 -0700

[Alasdair G. Kergon (agk2)]

On Mon, Oct 26, 2009 at 01:44:51PM -0000, Scott James Remnant wrote:
> This is by design, the code in 65-dmsetup.rules is deliberately making
> the snapshot origin the *LOWEST* possible priority.

Upstream I think we're going with giving the snapshot origin precedence.

But none of these solutions is satisfactory - it is a multi-valued property.
Either we find a way to recognise that, or we need to make it configurable
within LVM so the end user can choose which behaviour they prefer.

Alasdair

[Alasdair G. Kergon (agk2)]

On Mon, Oct 26, 2009 at 11:44:57PM +0000, Alasdair G Kergon wrote:
> But none of these solutions is satisfactory - it is a multi-valued property.
> Either we find a way to recognise that, or we need to make it configurable
> within LVM so the end user can choose which behaviour they prefer.

We could eventually go further, and use the power of udev to have a trigger
that automatically changes one of the UUIDs to make it unique.

Alasdair

[Soren Hansen (soren)]

Setting back to "Confirmed" as Kees agrees this should be fixed.

[Scott James Remnant (Canonical) (canonical-scott)]

Then change it ;-)

And enjoy all the errors you get during upgrades where people's filesystems suddenly change from the snapshot to the origin as they're mounted by UUID :p

[Soren Hansen (soren)]

On Tue, Oct 27, 2009 at 10:31:34AM -0000, Scott James Remnant wrote:
> Then change it ;-)

Sure. I intended to do so from the beginning. I just don't really feel
like shoving this into Karmic at this point.

> And enjoy all the errors you get during upgrades where people's
> filesystems suddenly change from the snapshot to the origin as they're
> mounted by UUID :p

I'm still struggling to come up with a use case where mounting the
(well, not "the" as much as "an arbitrary") snapshot is preferred over
mounting the origin.

The only problem I see is if people actually unnoticed have been
affected by this, and have simply started using the snapshot instead of
the origin, so changing it back will seem like data loss (since any
changes made to the snapshot suddenly is gone). In other words, I'm not
comfortable SRU'ing this into e.g. Hardy, but I think we should make the
change for Lucid and add a release note saying that if you relied on
this (I doubt anyone does so *on purpose*, but still), you will want to
do something to handle it (like point to the lv by name rather than
UUID).

[Phillip Susi (psusi)]

This is still misbehaving in lucid beta 1. I made a snapshot and was surprised to reboot and find I was running off it. The normal use for snapshots is as a read only backup. Maybe in lucid+1 it will start to make more sense to boot off the snapshot, since support for merging the snapshot back into the origin and replacing the old fs with the new one if it worked out went into kernel 2.6.33, but right now it does not make much sense.

[Steve Fisher (stefan-nicolaivic)]

Possibly users should be warned in some prominent location that if they're mounting by UUID then leaving an LVM snapshot in place could result in that being mounted on reboot.

Changing the UUID of the 'real' disk during live operation simply because it's been snapshotted sounds reasonably insane - there's a case to be made for that being somewhat immutable after boot.

It might make more sense to filter via mapper and/or by-path (I'm using by-path in LVM's filter right now to sanely strain the multipath devices out from regular sd* devices) if you're expecting to have stale LVM snapshots around at boot time.

A user-configurable choice might make for reasonable compromise.

[Dimitri John Ledkov (xnox)]

There is no perfect solution of where disk/by-uuid should point to for lvm2 devices & snapshots. It is well know, and by default we are not using them (e.g. in the installer, etc).

On the other hand for non-lvm2 / non-dm devices these links are useful.