Re: Trees in volumes

[Fabian Deutsch <fdeutsch redhat com>]

----- Original Message -----
> A non-trivial problem with LVM snapshots (including thinp snapshots)
> is that you end up with two completely identical file system volumes,
> including their volume UUID. By default, the LV snapshot isn't active,
> so two identical volume UUIDs aren't visible. But if both are active,
> things can become confused. With at least XFS (and I think also ext4)
> the new not yet default metadata checksumming includes prolific usage
> of the volume UUID throughout the metadata structures, so it becomes
> essentially impossible to change the volume UUID of a snapshot as it
> would require rewriting all the fs metadata.

Yes, correct.
As long as metadata checksums are not used in ext4, you can still set
a new UUID for each snapshot you create. This will allow activating them
at the same time.

> Btrfs avoids the problem because snapshots happen on subvolumes rather
> than the volume. Each subvolume (and snapshot) gets a new UUID.

Yes, indeed, btrfs is here sure a great solution. Besides this problem
you will also get smarter updates (you can create deltas) and better
de-duplication.
 
> I actually don't know how to resolve the problem of simultaneous use
> of LVs with identical fs volume UUIDs (which is itself a rather
> significant oxymoron); it means it's not possible to do something like
> a chroot or container based approach where the snapshot is the one
> where files are deleted and replaced during an OS upgrade (rather than
> deleting files underneath running applications), because both fs
> volumes can't be mounted at the same time (it's disallowed) and it's
> even risky having them active at the same time.

Yes, indeed - The initial problem is that the symlinks in /etc/disk/by-*
will just oint to one disk, when there are more than one FS with the same
uuid.

- fabian