> It doesn't work this way. The snapshots a and b are not based on the > same underlying subvolume. The gist is that you would keep changing A, > and take additional snapshots of A, such as a.1 a.2 a.3, and you can > do incremental send with 'btrfs send -p a.1 a.2' which describes the > difference between those two snapshots of A at their respective > moments in time. You could also do 'btrfs send -p a.2 a.3' or even > 'btrfs send -p a.1 a.3' > > But as there's no relationship between
snapshots a and b, I consider > it a bug/missing error handling feature, that btrfs send doesn't fail > in this case. By using -p you're claiming there is a parent-child > relationship between a and b, but there plainly isn't. They kind of are related though, since the two snapshots reference the same data blocks, and you can see it work in the first example with the 40MB of random data. However, I can replicate this odd behaviour the conventional way. btrfs sub create A mkdir A/dir dd if=/dev/urandom of=A/dir/server.jar bs=1024 count=40K btrfs sub snap -r A a cp --reflink=always A/dir/server.jar A/server.jar rm A/dir -rf btrfs sub snap -r A b btrfs send -p a b > out The out file is only 773 bytes. However, if you repeat all those same steps, but replace the dd with: wget -O A/dir/server.jar https://launcher.mojang.com/v1/objects/20c069d373e77265aaeeedb733f7051e294325a3/server.jar The resulting out file is 34MB.
<<attachment: remi.vcf>>
signature.asc
Description: OpenPGP digital signature
