The reason why I'm using reflinks instead of snapshots is because the
master subvolume is large and will contain hundreds of gigabytes worth
of data. Now if I change / remove, say 10 GB worth of data from the
master subvolume unrelated to the child subvolume I don't want those
gigabytes sent down the wire with btrfs send as they are unrelated. Also
I want to be able to after time, when required, add more data from the
master subvolume to the child. Thats why I can't split the master
subvolume into parts of related data.
On 2019-02-18 22:22, Chris Murphy wrote:
On Mon, Feb 18, 2019 at 12:58 PM André Malm <ad...@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.
