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

[Robert White <rwhite@pobox.com>]

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.