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

[Filipe Manana <fdmanana@gmail.com>]

On Fri, Aug 27, 2021 at 10:05 PM Darrell Enns <darrell@darrellenns.com> wrote:
>
> Inode number of places.sqlite is 400698. It's the same in both
> snapshots, as well as the current active subvolume.
>
> From 2nd snapshot (id 977):
>   Size: 83886080      Blocks: 163840     IO Block: 4096   regular file
> Device: 5fh/95d    Inode: 400698      Links: 1
> Access: (0640/-rw-r-----)  Uid: ( 1000/   denns)   Gid: ( 1000/   denns)
> Access: 2021-08-27 09:59:01.619570401 -0700
> Modify: 2021-08-27 10:06:43.952629419 -0700
> Change: 2021-08-27 10:06:43.952629419 -0700
>  Birth: 2021-08-07 20:16:37.080012116 -0700

Thanks.
A quick first look shows me that the cause is not what I initially
suspected - the clone operation that fails is not from the inode at
the send snapshot to the same inode at the send snapshot (cloning from
itself), but instead from the parent snapshot to the send snapshot.
The clone offset and length seem valid at first glance, as clone range
is within the eof of the inode in the parent snapshot and it's
properly aligned. So I'll have to recreate the same extent layout and
see if it fails, which will take a while.

Can you please keep those snapshots (IDs 977 and 881) for a few days,
in case of the need to get more debug information or to try a patch?

Also, I forgot to ask before, but you are not passing any clone roots
to "btrfs send" (-c command line argument), right?

Thanks, I'll get back to you later.


-- 
Filipe David Manana,

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