Volume/subvolume UUID uniqueness, was: BTRFS messes up snapshot LV with origin

Volume/subvolume UUID uniqueness, was: BTRFS messes up snapshot LV with origin

[Chris Murphy]

I don't know how to fix this but I've convinced myself there's at
least a small problem. And not just with LVM snapshots as in the
originating thread.

- Via seed device method of creating a Btrfs volume, the resulting
volume gets a new UUID. The volume UUID from the seed device doesn't
pass through, is not inherited / copied. Therefore there's already
recognition that snapshotting a Btrfs volume, which is what volume
creation from a seed device effectively is, should result in the new
volume getting a new UUID.

Therefore it seems reasonable a mechanism to support new volume UUIDs
upon LVM snapshots being taken is needed. Maybe leveraging existing
seed code can help, consider existing volume data a virtual seed
device, and the remaining free space as a virtual added device to
enable changing volume UUID rather than rewriting possibly piles of
UUIDs.


- While the seed device method of creating a Btrfs volume results in a
new volume UUID, subvolume UUIDs from the seed pass through to the new
volume. Since I can create many new volumes from one seed device, in
effect I'm creating many instances of subvolumes with identical UUIDs
and can now no longer be differentiated, locally and remotely. This
seems to be a much bigger problem than the LVM case, since it occurs
with only Btrfs tools being used.

The grandiose idea of UUIDs is persistence in identifying a specific
object/resource for all time, anywhere in the universe. Reducing this
to something practical, it should enable a way to identify an object
or resource within one or two human lifetimes, within our solar
system. Yet the current implementation has broken this on a much
shorter time scale, on a single computer.

Since we recognize subvolume snapshots should get new subvolume UUIDs,
and volume snapshots via seed device method creation of new volumes
get new volume UUIDs; a volume snapshot of course is also snapshotting
the subvolumes too, so the subvolume UUIDs can't pass through the way
they do right now. It's not correct behavior.

Another matter is what to do with parent uuid and snapshot
relationship metadata in the new volume. Assume all subvolumes get new
UUIDs on the new volume, there are three potentials:
1. parent uuid is always blank, no relationships between subvolumes is preserved
2. parent uuid is the uuid of its identical "mirror" (the original) in
the seed device.
3. parent uuid is the new uuid of its relative parent on the current
new volume, preserving relationships between subvolumes and snapshots.

I think any of those three are better than UUID duplication (recycling
actually). Maybe I'm not thinking of a use case for preserving these
UUIDs but at the moment I think it's specious. We can't be attached to
specific UUIDs, the instant a subvolume is effectively snapshot by LVM
or Btrfs seed device, it's a unique object/resource, and should have
its own URN. Afterall by default these objects are read/write. Maybe
if by default they were readonly I could be convinced of the validity
of UUID preservation.


-- 
Chris Murphy

Re: Volume/subvolume UUID uniqueness, was: BTRFS messes up snapshot LV with origin

[Robert White]

On 11/22/2014 11:52 AM, Chris Murphy wrote:
> I don't know how to fix this but I've convinced myself there's at
> least a small problem. And not just with LVM snapshots as in the
> originating thread.

Yes.

You also run into this problem if you use multipath hardware but haven't 
configured multipath support to be transparent.

In any system, when you mix layers of abstraction you get problems.

LVM snapshots make "the same disk blocks" appear in multiple places but 
don't actually present "the same disk blocks" since writes to "those 
blocks" will cause COW divergence.

This violates the Universally Unique constraint of the UUID promise.

None of these are problems with the respective systems working at their 
respective jobs, they are inherent problems with the fact that a servant 
can not serve two masters.

As far as the parentage trees of subvolumes... I've been trying to get 
_anybody_ on here to recognize the problems already inherent in that 
system as implemented. Take a couple snapshots of a subvolume, and then 
send those subvolumes to another file system with send/receive, and then 
do "btrfs subvolume list -u -q" on the two filesystems and tell me that 
mess makes sense. Or try to recreate a subvolume from its snapshot in a 
way that doesn't shatter the relationships in your backup scheme. (I'm 
researching for a couple patches but I'm not expecting a warm reception 
given the silence to date).

So yea, UUID plus copy plus mirror plus snapshot equals a trip to caveat 
city.

Re: Volume/subvolume UUID uniqueness, was: BTRFS messes up snapshot LV with origin

[Robert White]

On 11/22/2014 02:50 PM, Robert White wrote:
> Take a couple snapshots of a subvolume, and then
> send those subvolumes to another file system with send/receive, and then
> do "btrfs subvolume list -u -q" on the two filesystems and tell me that
> mess makes sense. Or try to recreate a subvolume from its snapshot in a
> way that doesn't shatter the relationships in your backup scheme. (I'm
> researching for a couple patches but I'm not expecting a warm reception
> given the silence to date).

(ASIDE In particular use "btrfs sub send -c SNAP1 SNAP2" and then "btrfs 
sub send -c SNAP2 SNAP3" etc before doing the "btrfs sub list -u -q" to 
view the mess I speak of.)