Re: BTRFS messes up snapshot LV with origin

[Robert White <rwhite@pobox.com>]

On 11/25/2014 07:22 PM, Duncan wrote:
>>From my perspective, however, btrfs is simply incompatible with lvm
> snapshots, because the basic assumptions are incompatible.  Btrfs assumes
> UUIDs will be exactly what they say on the label, /unique/, while lvm's
> snapshot feature directly breaks that uniqueness by copying the (former)
> UUID, thus making the former UUID no longer unique and thus no longer
> truly UUID.  Thus, part of the lvm /feature/ of snapshots is in direct
> contradiction to a basic assumption of btrfs, that UUIDs are exactly
> that, unique, making that feature directly incompatible with btrfs on a
> very basic level.

A finer point here. LVM doesn't "copy" the UUID. AN LVM snapshot is a 
copy-on-write entity so it _exposes_ the single sector(s) of the 
superblock(s) in both views of the underlying storage. This is universal 
to the idea of a snapshot. Just as a "btrfs subvol snap /old /new" 
exposes all the "unique" elements of "/old" under the name "/new" (in 
preparation for the user to implement subsequent divergence); "lvmcreate 
--snapshot Old New" causes every block-N of Old to be identically 
available as block-N of New (in preparation for the user to implement 
subsequent divergence).

In point of fact the LVM snapshot operation is a zero-copy operation at 
its heart. After the snapshot is established, when a block in modified 
in Old, it's original content is saved in New. When blocks are written 
in New, they are written in place and the reference to the block content 
in Old is overwritten.

This is the reason that fsfreeze is unnecessary for things above LVM 
snapshots as the instant-in-time divergence is _instant_. It's not that 
LVM goes out and does an fsfreeze equivalent action, its that the switch 
to write-divergence is essentially atomic. A bunch of metatdata is setup 
and then all-at-once one write behavior is switched with another by 
re-mapping the device access routines.

So while you may have a point about btrfs being unprepared for LVM, 
neither party is particularly "at fault" in any way.

The "damn you photocopier for making photocopies so identically" nature 
of your problem with LVM seems to be leading you to misplaced conclusions.

If you need to harmonize these sorts of things, you need to be able to 
re-write blocks in question with disambiguating information (like new 
UUIDS) or restrict your accesses in some other manner.

If you are waiting for someone to "code it up" perhaps you should do so. 
But it will _never_ be automatic because the use cases that don't match 
your expectations may need the founding assumptions to be as they are today.

In other words, your belief that your position is "entirely logical" may 
be a little off, particularly if you think LVM is "Copying" things when 
it does a snapshot.

As previously stated XFS solved this problem by providing a tool that 
would change the UUID of a file system. This tool cold then be pointed 
at either (or both) the original and/or snapshot volumes as needed.

I don't see a "re-make the btrfs" option for changing UUIDs and LVM 
doesn't care _at_ _all_ about what is actually in its volumes (okay, 
lvresize has some fsck nonsense, but that's just messy).

It might even be "wrong" to try to harmonize those features, like trying 
to put a manual clutch into a car with an automatic transmission... it 
may just not fit.

Given that BTRFS want's to play in the same level of abstraction as LVM, 
its kind of a given that they'll butt heads over things like conflicting 
definitions of what it means to take a snapshot.