Re: Backup failing with "failed to clone extents" error

[Filipe Manana <fdmanana@gmail.com>]

On Tue, Aug 31, 2021 at 12:20 PM Filipe Manana <fdmanana@gmail.com> wrote:
>
> 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.

Also, what's the btrfs-progs version being used? (type "btrfs
--version" to get it)

>
> Thanks!
>
>
>
> --
> Filipe David Manana,
>
> “Whether you think you can, or you think you can't — you're right.”



-- 
Filipe David Manana,

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