Document send and reflink

[kdave]

Document question about send stream size and reflinks.

• https://bugzilla.kernel.org/show_bug.cgi?id=216148
• https://www.reddit.com/r/btrfs/comments/wljt4s/btrfs_send_breaks_reflinks
• Answer https://lore.kernel.org/linux-btrfs/20221008005704.795b44b0@crass-HP-ZBook-15-G2/

[bhelm]

As a user, i expected btrfs send to also transfer reflinks and struggeled for hours with this problem.

The problem was drastic as we use btrfs snapshots as backups; in the current case, i had a server with a 150GB SSD that had 50GB files on it, with a non-reflinked size of 200GB. So the backup took 200GB of storage, which is not optimal. But the main problem is that it took alot of manual work to transfer the snapshot back to the server in a recovery scenario, as the 200GB would not fit on the 150GB server.

The confusing thing is that it sometimes works, sometimes not, and that there is indeed no documentation about this in btrfs-send 6.2.

Here is my minimal reproduction example:

btrfs sub create /test
cd /test
dd if=/dev/random of=works.1 bs=1M count=1
cp --reflink=always works.1 works.2
zip test.zip works.1
cp --reflink=always test.zip test.2.zip 
sleep 1
btrfs sub snap -r /test /test-r > /dev/null && btrfs send /test-r | pv -b > /dev/null; btrfs sub del /test-r >/dev/null

If all reflinks are working, it should send 2MB. if all reflinks are not working, it should send 4MB. In my tests on linux 5.10 and 6.2, its always 3MB, which is in between. The reflink for the random file works, the reflink for the zip file not.

Having a option to figure out the reflinks or at least some documentation in btrfs-send would be great!

Thank you.

[adam900710]

Tried myself, indeed the send string do the clone properly for works.2, but not for test.2.zip, this is using the latest for-next branch.

subvol          ./ro_snap                       uuid=510d6e31-1f9e-054f-9d3d-a33bd3fa42ee transid=11
chown           ./ro_snap/                      gid=0 uid=0
chmod           ./ro_snap/                      mode=755
mkfile          ./ro_snap/o257-8-0
rename          ./ro_snap/o257-8-0              dest=./ro_snap/works.1
write           ./ro_snap/works.1               offset=0 len=49152
write           ./ro_snap/works.1               offset=49152 len=49152
[...skip the writes ...]
write           ./ro_snap/works.1               offset=983040 len=49152
write           ./ro_snap/works.1               offset=1032192 len=16384
chown           ./ro_snap/works.1               gid=0 uid=0
chmod           ./ro_snap/works.1               mode=644
utimes          ./ro_snap/works.1               atime=2024-08-12T06:54:44+0800 mtime=2024-08-12T06:53:45+0800 ctime=2024-08-12T06:53:45+0800
mkfile          ./ro_snap/o258-9-0
rename          ./ro_snap/o258-9-0              dest=./ro_snap/works.2
clone           ./ro_snap/works.2               offset=0 len=1048576 from=./ro_snap/works.1 clone_offset=0
chown           ./ro_snap/works.2               gid=0 uid=0
chmod           ./ro_snap/works.2               mode=644
utimes          ./ro_snap/works.2               atime=2024-08-12T06:54:06+0800 mtime=2024-08-12T06:54:06+0800 ctime=2024-08-12T06:54:06+0800
mkfile          ./ro_snap/o260-10-0
rename          ./ro_snap/o260-10-0             dest=./ro_snap/test.zip
write           ./ro_snap/test.zip              offset=0 len=49152
write           ./ro_snap/test.zip              offset=49152 len=49152
[...skip the writes ...]
write           ./ro_snap/test.zip              offset=983040 len=49152
write           ./ro_snap/test.zip              offset=1032192 len=16708
chown           ./ro_snap/test.zip              gid=0 uid=0
chmod           ./ro_snap/test.zip              mode=644
utimes          ./ro_snap/test.zip              atime=2024-08-12T06:54:44+0800 mtime=2024-08-12T06:54:44+0800 ctime=2024-08-12T06:54:44+0800
mkfile          ./ro_snap/o261-11-0
rename          ./ro_snap/o261-11-0             dest=./ro_snap/test.2.zip
write           ./ro_snap/test.2.zip            offset=0 len=49152
write           ./ro_snap/test.2.zip            offset=49152 len=49152
[...skip the writes ...]
write           ./ro_snap/test.2.zip            offset=983040 len=49152
write           ./ro_snap/test.2.zip            offset=1032192 len=16708
chown           ./ro_snap/test.2.zip            gid=0 uid=0
chmod           ./ro_snap/test.2.zip            mode=644
utimes          ./ro_snap/test.2.zip            atime=2024-08-12T06:55:16+0800 mtime=2024-08-12T06:55:16+0800 ctime=2024-08-12T06:55:16+0800
utimes          ./ro_snap/                      atime=2024-08-12T06:54:48+0800 mtime=2024-08-12T06:55:16+0800 ctime=2024-08-12T06:55:16+0800

Meanwhile inside the original subvolume both works.2 and test.2.zip are reflinks.

        item 10 key (257 INODE_ITEM 0) itemoff 15647 itemsize 160
                generation 8 transid 10 size 1048576 nbytes 1048576
                block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
                sequence 1 flags 0x0(none)
        item 11 key (257 INODE_REF 256) itemoff 15630 itemsize 17
                index 2 namelen 7 name: works.1
        item 12 key (257 EXTENT_DATA 0) itemoff 15577 itemsize 53
                generation 8 type 1 (regular)
                extent data disk byte 13631488 nr 1048576
                extent data offset 0 nr 1048576 ram 1048576
                extent compression 0 (none)
        item 13 key (258 INODE_ITEM 0) itemoff 15417 itemsize 160
                generation 9 transid 9 size 1048576 nbytes 1048576
                block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
                sequence 1 flags 0x0(none)
        item 14 key (258 INODE_REF 256) itemoff 15400 itemsize 17
                index 3 namelen 7 name: works.2
        item 15 key (258 EXTENT_DATA 0) itemoff 15347 itemsize 53
                generation 8 type 1 (regular)
                extent data disk byte 13631488 nr 1048576
                extent data offset 0 nr 1048576 ram 1048576
                extent compression 0 (none)
        item 16 key (260 INODE_ITEM 0) itemoff 15187 itemsize 160
                generation 10 transid 10 size 1048900 nbytes 1052672
                block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
                sequence 70 flags 0x0(none)
        item 17 key (260 INODE_REF 256) itemoff 15169 itemsize 18
                index 6 namelen 8 name: test.zip
        item 18 key (260 EXTENT_DATA 0) itemoff 15116 itemsize 53
                generation 10 type 1 (regular)
                extent data disk byte 14680064 nr 1052672
                extent data offset 0 nr 1052672 ram 1052672
                extent compression 0 (none)
        item 19 key (261 INODE_ITEM 0) itemoff 14956 itemsize 160
                generation 11 transid 11 size 1048900 nbytes 1052672
                block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
                sequence 1 flags 0x0(none)
        item 20 key (261 INODE_REF 256) itemoff 14936 itemsize 20
                index 7 namelen 10 name: test.2.zip
        item 21 key (261 EXTENT_DATA 0) itemoff 14883 itemsize 53
                generation 10 type 1 (regular)
                extent data disk byte 14680064 nr 1052672
                extent data offset 0 nr 1052672 ram 1052672
                extent compression 0 (none

So it's indeed a bug.

@fdmanana Mind to have a look on this? Or it's a known problem?

[fdmanana]

In this particular example it never worked because the end of the extent is not sector size aligned.
But since it matches the size of the file (eof, i_size), we can actually clone it as it's the only exception allowed by the reflink syscall for cloning unaligned ranges.

I've sent a patch for this: https://lore.kernel.org/linux-btrfs/e764923c5a0bca3cdf90199da34747b38094a390.1723469840.git.fdmanana@suse.com/

Qu, please change back the subject to what it was... It's ambiguous because we'll always have cases where we won't clone (like too many backrefs and we skip detecting clone sources due to too high performance penalty for example, or some cases when the source and destination filesystems have different sector sizes, etc).