csum errors on negative root id?

csum errors on negative root id?

[Ross Vandegrift]

Hello,

I recently saw these in my dmesg, on 4.19.160:
  BTRFS warning (device dm-20): csum failed root -9 ino 1303 off 0 csum 0x47abffd5 expected csum 0xd5f0d335 mirror 1
  BTRFS warning (device dm-20): csum failed root -9 ino 1303 off 0 csum 0x47abffd5 expected csum 0xd5f0d335 mirror 1

I'm confused by a few things here:
- does the negative root id mean something, or is this a bug?
- inode 1303 doesn't seem to exist.
- This is a standalone drive, is this about a dup metadata block?

Details on the fs:
$ sudo btrfs fi show /mnt/storage
Label: none  uuid: 6a2038fb-a9b4-4720-a441-c084610e4295
        Total devices 1 FS bytes used 4.66TiB
        devid    1 size 7.28TiB used 5.72TiB path /dev/mapper/storage

$ sudo btrfs fi df /mnt/storage
Data, single: total=4.68TiB, used=4.66TiB
System, DUP: total=32.00MiB, used=768.00KiB
Metadata, DUP: total=536.45GiB, used=4.95GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
$ sudo btrfs inspect-internal subvolid-resolve -- -9 /mnt/storage
ERROR: -9: negative value is invalid.
$ sudo btrfs inspect-internal inode-resolve 1303 /mnt/storage
ERROR: ino paths ioctl: No such file or directory

Please keep me CCed, thanks!

Ross

Re: csum errors on negative root id?

[Qu Wenruo]

On 2020/12/17 上午3:28, Ross Vandegrift wrote:
> Hello,
>
> I recently saw these in my dmesg, on 4.19.160:
>    BTRFS warning (device dm-20): csum failed root -9 ino 1303 off 0 csum 0x47abffd5 expected csum 0xd5f0d335 mirror 1
>    BTRFS warning (device dm-20): csum failed root -9 ino 1303 off 0 csum 0x47abffd5 expected csum 0xd5f0d335 mirror 1
>
> I'm confused by a few things here:
> - does the negative root id mean something, or is this a bug?

-9 means data reloc tree. It's not a bug.

> - inode 1303 doesn't seem to exist.

The inode is in data reloc tree, which is not visible for users.

But this means you have a lot of uncleaned inodes in data reloc tree.

> - This is a standalone drive, is this about a dup metadata block?

Nope, just some data didn't match its csum.

Btrfs scrub should also report such csum mismatch.
But scrub would report the file path so that you can remove the
offending file and then continue balance.

Thanks,
Qu
>
> Details on the fs:
> $ sudo btrfs fi show /mnt/storage
> Label: none  uuid: 6a2038fb-a9b4-4720-a441-c084610e4295
>          Total devices 1 FS bytes used 4.66TiB
>          devid    1 size 7.28TiB used 5.72TiB path /dev/mapper/storage
>
> $ sudo btrfs fi df /mnt/storage
> Data, single: total=4.68TiB, used=4.66TiB
> System, DUP: total=32.00MiB, used=768.00KiB
> Metadata, DUP: total=536.45GiB, used=4.95GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
> $ sudo btrfs inspect-internal subvolid-resolve -- -9 /mnt/storage
> ERROR: -9: negative value is invalid.
> $ sudo btrfs inspect-internal inode-resolve 1303 /mnt/storage
> ERROR: ino paths ioctl: No such file or directory
>
> Please keep me CCed, thanks!
>
> Ross
>