Fwd: btrfs receive fails with "failed to clone extents"

Hi,

(Sorry I forgot to CC linux-btrfs)

On Thu, Sep 23, 2021 at 3:32 AM Qu Wenruo [off-list ref] wrote:

On 2021/9/23 09:40, Yuxuan Shui wrote:

quoted

On Thu, Sep 23, 2021 at 2:34 AM Yuxuan Shui [off-list ref] wrote:

quoted

Hi,

On Thu, Sep 23, 2021 at 12:24 AM Qu Wenruo [off-list ref] wrote:

quoted

On 2021/9/23 03:37, Yuxuan Shui wrote:

quoted

Hi,

The problem is as the title states. Relevant logs from `btrfs receive -vvv`:

    mkfile o119493905-1537066-0
    rename o119493905-1537066-0 ->
shui/programs/treeusage/target/release/build/zstd-sys-506c8effd111251c/out/include/zstd.h
    utimes shui/programs/treeusage/target/release/build/zstd-sys-506c8effd111251c/out/include
    clone shui/programs/treeusage/target/release/build/zstd-sys-506c8effd111251c/out/include/zstd.h
- source=shui/.cargo/registry/src/github.com-1ecc6299db9ec823/zstd-sys-1.6.1+zstd.1.5.0/zstd/lib/zstd.h
source offset=0 offset=0 length=131072
    ERROR: failed to clone extents to
shui/programs/treeusage/target/release/build/zstd-sys-506c8effd111251c/out/include/zstd.h:
Invalid argument

stat of shui/.cargo/registry/src/github.com-1ecc6299db9ec823/zstd-sys-1.6.1+zstd.1.5.0/zstd/lib/zstd.h,
on the receiving end:

    File: /mnt/backup/home/backup-32/shui/.cargo/registry/src/github.com-1ecc6299db9ec823/zstd-sys-1.6.1+zstd.1.5.0/zstd/lib/zstd.h
    Size: 145904 Blocks: 288 IO Block: 4096 regular file

Looks to me the range of clone is within the boundary of the source
file. Not sure why this failed?

The most common reason is, you have changed the parent subvolume from RO
to RW, and modified the parent subvolume, then converted it back to RO.

This is 100% not the case. I created these snapshots as RO right
before sending, and definitely haven't
changed them to RW ever.

Besides that, I straced the btrfs command and this clone ioctl
definitely looks valid, irregardless of whether the parent snapshot
has been changed or not. The length looks to be aligned (128k), and
the range is within the source file. Why did the clone fail?

The clone source must not have certain bits like NODATACOW.

lsattr doesn't show anything. The entire file system is mounted with
nodatasum, though. But I assume if this bit is the problem, send won't
fail just on this particular file?

If non-incremental send stream works, then it's almost certain it's the
received UUID bug we're working on.

I haven't tried non-incremental. If by received UUID bug you meant
this one: https://lore.kernel.org/linux-btrfs/87blnsuv7m.fsf@gmail.com/T/ (local)
, then I don't think this is the one. I don't have duplicated received
UUIDs on either end.

Thanks,
Qu

quoted

quoted

quoted

Btrfs should not allow such incremental send at all.

We're already working on such problem, but next time if you want to
modify a RO subvolume which could be the parent subvolume of incremental
send, please either do a snapshot then modify the snapshot, or just
don't do it.

Thanks,
Qu

quoted

Sending end has 5.14.6 and btrfs-progs 5.14, receiving end has 5.14.6
and btrfs-progs 5.13.1

--

Regards
Yuxuan Shui

--

Regards
Yuxuan Shui