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. -- Chris Murphy
