Can I continue incremental send after subvol is split?

I asked in btrfs IRC, got suggestion but when I try to actually do it, I got error.

So I am trying to describe my testing setup in full here.

  1. create a new subvol subvol-A
btrfs subvol create /mnt/send/subvol-A
  1. Create 8 100MB files
$ for i in 1 2 3 4 5 6 7 8;do dd if=/dev/random of=subvol-A/file0$i.img bs=1M count=100;done
  1. Create readonly snapshot of subvol-A as Subvol-A-0
btrfs subvol snap -r /mnt/send/subvol-A /mnt/send/readonly/subvol-A-00
  1. send over
btrfs send /mnt/send/readonly/subvol-A-00 | btrfs receive /mnt/receive/received/
  1. modify something inside subvol-A and send incrementally
mkdir /mnt/send/subvol-A/f1
mv /mnt/send/subvol-A/file0{1,2,3,4}.img /mnt/send/subvol-A/f1
btrfs subvol snap -r /mnt/send/subvol-A /mnt/send/readonly/subvol-A-01
btrfs send -p /mnt/send/readonly/subvol-A-00 /mnt/send/readonly/subvol-A-01 | btrfs receive /mnt/receive/received/
  1. Next, convert f1 “from folder to subvol”
mv /mnt/send/subvol-A/f1 /mnt/send/subvol-A/f1.tmp
btrfs subvol create /mnt/send/subvol-A/f1
mv /mnt/send/subvol-A/f1.tmp/* /mnt/send/subvol-A/f1/
rmdir /mnt/send/subvol-A/f1.tmp
  1. send change of to subvol-A incrementally
btrfs subvol snap -r /mnt/send/subvol-A /mnt/send/readonly/subvol-A-10 #here as f1 is a subvol, it is not included in this snapshot

btrfs subvol send -p /mnt/send/readonly/subvol-A-01 /mnt/send/readonly/subvol-A-10 |  btrfs receive /mnt/receive/received/
# so now subvol-A is sent
  1. Create snapshot of subvol-A/f1
btrfs subvol snap -r /mnt/send/subvol-A/f1 /mnt/send/readonly/f1-10

Now the question:

How to efficiently (in terms of transmitted data volume) send f1-10 over?

Update: add btrfs-mailling list topic link


btrfs send -c /mnt/send/readonly/subvol-A-10  mnt/send/readonly/f1-10

As long as the -c snapshot is on both send and receive file systems, it should clone extents for files in f1-10 from subvol-A-10.

Because the files are also in /mnt/send/readonly/subvol-A-00 and it too is on both send and receive file systems, you could use it as the -c snapshot. Same outcome.

1 Like
btrfs send -c subvol-A-10/ f1-10/ > cA10f1-10.btrfs.sendstream
At subvol f1-10/
ERROR: parent determination failed for 330
btrfs send -p subvol-A-01/ f1-10/ > cA01f1-10.btrfs.sendstream
At subvol f1-10/
[root@amdf readonly] 2021-05-30 23:20:41
# ls -l
-rw-r--r--. 1 root root 2400 May 30 23:20 cA01f1-10.btrfs.sendstream

Looks like -p worked, and it’s efficient based on the file size. Whereas -c failed. Not sure why. It might be worth an upstream question. I was under the impression -c has one less of a check than -p, hence the man page requirement of ensuring the snapshots passed for this option are identical.

Note that mv between subvolumes results in an initial failure to rename, because the two namespaces are independent, similar to separate file systems. So mv falls back to cp but specifically to --reflink=auto which means in this case they are reflink copies.

It seems yes, as I can do cat <stream> | btrfs receive . and the folder contents are correct.

Now the question is, when I do the same with my actually data, for a folder size of 2.1T, the -p command generated 1T data.