btrfs send clone use case

btrfs send clone use case

[Chris Murphy]

I haven't previously heard of this use case for -c option. It seems to
work (no errors or fs weirdness afterward).

The gist: send a snapshot from drive 1 to drive 2; rw snapshot of the
drive 2 copy, and then make changes to it, then make an ro snapshot;
now send it back to drive 1 *as an incremental* send.

[dated subvolumes are ro, undated ones are rw]


# btrfs send /brick1/chrishome-20151128 | btrfs receive /brick2
# btrfs sub snap /brick2/chrishome-20151128 /brick2/chrishome
## make some modifications to chrishome contents
# btrfs sub snap -r /brick2/chrishome /brick2/chrishome-20151230
# btrfs send -p /brick2/chrishome-20151128 chrishome-20151230 | btrfs
receive /brick1
ERROR: check if we support uuid tree fails - Operation not permitted
At subvol chrishome:20151230/

However,

# btrfs send -p /brick2/chrishome-20151128 -c
/brick2/chrishome-20151128 chrishome-20151230 | btrfs receive /brick1

works. And it's fast (it's ~100G so I'd know if it weren't sending an
increment).

chrishome-20151128 is obviously identical on both sides in this case;
but I guess -c just acts to explicitly confirm this is true? The
brick2/chrishome-20151128 has a Received UUID that
matches the UUID of brick1/chrishome-20151128, so it seems their
identical states should be known?

Slightly confusing though: brick1/chrishome:20151230 (the one
resulting from the successful -p -c command) has the same Parent UUID
and Received UUID, which is the UUID for brick1/chrishome:20151128.
That's not really its parent, since it's a received subvolume I'd
expect this to be -, like it is for any other received subvolume
(which doesn't really have a parent).

Anyway it seems to be working.

-- 
Chris Murphy

Re: btrfs send clone use case

[Duncan]

Chris Murphy posted on Thu, 31 Dec 2015 13:54:42 -0700 as excerpted:

> I haven't previously heard of this use case for -c option.
> It seems to work (no errors or fs weirdness afterward).
> 
> The gist:
> send a snapshot from drive 1 to drive 2;
> rw snapshot of the drive 2 copy,
> and then make changes to it,
> then make an ro snapshot;
> now send it back to drive 1 *as an incremental* send.

While as you likely know my own use-case doesn't use send/receive, based 
on previous on-list discussion, I considered this the obvious workaround 
to the problem of the current send stream format not including enough 
inheritance metadata to allow send/receive to properly handle a /reverse/ 
send -p.

Where -p works, it's the most efficient method, but due to this lack of 
send-stream inheritance metadata, it apparently can't work in the reverse 
case, where the usual receive end is now the send end.

But doing -c clones, while not /quite/ as efficient as -p because more 
metadata is sent, is still far more efficient than doing a full send, and 
can work in this reverse case where the original send side is now the 
receive side because it's not as strict as -p, being rather more metadata 
verbose in place of that strictness, where the -p option would fail due 
to strictness and lack of appropriate inheritance metadata in the stream 
format.

That -p mode missing inheritance metadata, being effectively just one 
more item, would still be much more efficient than using -c clones, as 
the clone format is generally more metadata-verbose in ordered to 
properly identify per-extent clones, but it's simply not there in the 
current format.  When the send format is eventually version-bumped, this 
additional metadata item should be included, making send -p work in these 
reverse-send cases, but they ideally want to do just one more "final"
send-stream format bump including all changes they've found to be needed, 
so they're holding off on the format bump for the moment, so as to be 
able to include anything else they've overlooked when they do finally do 
it.

That's as I understand the state of send/receive, anyway, being 
interested in it on-list, but not being a current user.  But this usage 
of -c being almost precisely that "reverse-send" usage, only with an 
additional change thrown in at the normal receive side before the send, 
I'd actually have been surprised if it /didn't/ work as you outlined. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman