Re: Btrfs send with parent different size depending on source of files.

[Chris Murphy <lists@colorremedies.com>]

On Mon, Feb 18, 2019 at 12:58 PM André Malm <admin@sheepa.org> wrote:

> Basically what I'm trying to achieve is having a "reference" / "master"
> btrfs subvolume where i add / edit / remove files continuously. From
> where i can cp --reflink=always some of those files to new "child"
> subvolumes as needed. As long as the files are still in the master
> subvolume I'll only send the diff of the data. The plan is to have this
> master subvolume across multiple remote machines (synced with rsync or
> perhaps btrfs send / receive) and being able to update / change it as
> needed but always only sending the diffs of the child subvolumes. Maybe
> this is a bit optimistic.

I'm not sure what you get out of this method that depends on reflink
rather than just making read only snapshots.

Why don't you create subvolume A as the master, read-write. And once
it's in the "master state" you want, just snapshot it:

btrfs sub snap -r A A.20190218-master

And now continue to make changes to A subvolume, and on whatever
schedule you want:

btrfs sub snap -r A A.20190218-1412
btrfs sub snap -r A A.20190218-1850
btrfs sub snap -r A A.20190219-0920

And now you can "compare" the difference to master at anytime:

btrfs send -p A.20190218-master A.20190218-1850 -f output (or pipe to receive)

*shrug* I'm just not understanding what your use case gains out of
doing a refink copy to another subvolume rather than just make a read
only snapshot.

Is it that subvolume A must accept changes, but itself cannot be the
"master"? And you're selectively reflink copying files from A to B
such that B is the only "master"? That's fine but then I'd say you
don't need any A snapshots, you need B snapshots where:

btrfs sub snap -r B B.20190218-master
btrfs sub snap -r B B.20190219-0920
btrfs send -p B.20190218-master B.20190219-0920 -f output (or pipe to receive)

And so on...

Anyway, my point isn't that you're doing it wrong. I'm jut not
understanding the advantage of doing it the way you're doing it; and
it should be clear by now that most people on the list aren't using
'btrfs send' to compute the difference between two otherwise unrelated
subvolumes.

Part of this *might* be because of how ZFS snapshots work, and Btrfs
users maybe just adopted the same logic due in large part to more
limitations on the ZFS implementation: snapshots are always read only,
incremental send is only done between snapshots of the same dataset,
datasets can't be deleted  until all snapshots are deleted, there are
no reflinks, and no doubt some things I'm forgetting.


-- 
Chris Murphy