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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
