Re: Trees in volumes

----- 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
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

- fabian

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]