On Tue, Aug 31, 2021 at 3:46 AM Darrell Enns <darrell@darrellenns.com> wrote:
>
> Debug output from the latest patch attached. Here's the error:
> BTRFS info (device dm-3): clone: -EINVAL other, src 400186 (root 2792)
> dst 400186 (root 2792), off 79134720 destoff 79134720 len 4751360 olen
> 4751360, src i_size 83886080 dst i_size 83886080 bs 4096 remap_flags 0

Yep, the same weird thing as before.

So the receiving filesystem gets that error, which is perfectly valid
since we are asking to clone from the same inode to the same inode in
the same root (snapshot) with the same source and destination offsets
- source range and target range overlap, whence the error.

However, if we go the dmesg log:

[   99.834090] BTRFS info (device dm-0): send: clone_range() start ino
400698 offset 79134720 send root 977, clone root 881 ino 400698 offset
79134720 data_offset 491520 len 4751360 disk_byte 308100730880
clone_src_i_size 83886080 next_write_offset 79134720
[   99.834094] BTRFS info (device dm-0): send: clone_range() step 1
ino 400698 offset 79134720, root offset 79134720 ino 400698
data_offset 491520 len 4751360, key.offset 78675968 ext_len 5210112
clone_data_offset 32768 found disk_byte 308100730880 next_write_offset
79134720
[   99.834096] BTRFS info (device dm-0): send: clone_range() step
2-1-2 ino 400698 offset 79134720, root offset 79134720 ino 400698
data_offset 491520 len 4751360, clone_len 4751360
[   99.834112] BTRFS info (device dm-0): send: clone_range() end ino
400698 offset 79134720 send root 977, clone root 881 ino 400698 offset
79134720 data_offset 491520 len 0 disk_byte 308100730880
clone_src_i_size 83886080 next_write_offset 79134720 ret 0

We see that send is issuing a clone command using different roots
(snapshots) for the clone operation (send root is 977 and clone root
is 881).
The root/snapshot IDs are different in the source and destination
filesystems - that's normal and it's what happens most of the time.
However I don't understand how is the inode number different, nor much
less how the receiver attempts to use the same root/snapshot as both
the source and destination for the clone operation - it should use
different roots/snapshots.

Ok, so, here's another kernel debug patch and also a patch for
btrfs-progs, both added as attachments.

The kernel one also at:  https://pastebin.com/raw/nfHfRuy7
And the progs one also at:  https://pastebin.com/raw/9CbN9C0H

When you run 'btrfs receive', you'll have to pass '-vvv' to it in
order to get the debug output.

Also, please provide the output of:

1) btrfs subvolume list -puqR <source fs mount path>
2) btrfs subvolume list -puqR <destination fs mount path>
3) cat /proc/mounts

I'm starting to suspect that somewhere, possibly the receiving side,
we make confusion with the snapshot uuids or generate wrong paths for
the clone operation.

Thanks!



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”