Re: BTRFS scrub reports an error but check doesn't find any errors.

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2021/7/26 上午1:39, Dave T wrote:
> What does the list recommend I do in this case?
>
> starting btrfs scrub ...
> scrub done for 56cea9cf-5374-4a43-b19d-6b0b143dc635
> Scrub started:    Sun Jul 25 00:40:43 2021
> Status:           finished
> Duration:         2:52:45
> Total to scrub:   1.26TiB
> Rate:             113.72MiB/s
> Error summary:    read=1

Scrub checks the csum for data and metadata, while btrfs-check only
checks the metadata, it doesn't check the csum of data, unless with
--check-data-csum option.

>    Corrected:      0
>    Uncorrectable:  1
>    Unverified:     0
> ERROR: there are uncorrectable errors
>
> dmesg | grep "checksum error at" | tail -n 20
> (no output)

I'm more interested in this problem, scrub finds one csum error but no
output is pretty weird already.

>
> # dmesg | grep -i checksum
> [  +0.001698] xor: automatically using best checksumming function   avx
> (not related to BTRFS, right?)
>
> # btrfs fi us /path/to/xyz
> Overall:
>      Device size:                   2.73TiB
>      Device allocated:              1.26TiB
>      Device unallocated:            1.47TiB
>      Device missing:                  0.00B
>      Used:                          1.12TiB
>      Free (estimated):              1.60TiB      (min: 888.70GiB)
>      Free (statfs, df):             1.60TiB
>      Data ratio:                       1.00
>      Metadata ratio:                   2.00
>      Global reserve:              512.00MiB      (used: 0.00B)
>      Multiple profiles:                  no
>
> Data,single: Size:1.25TiB, Used:1.11TiB (89.38%)
>     /dev/mapper/userluks    1.25TiB
>
> Metadata,DUP: Size:6.00GiB, Used:5.26GiB (87.67%)
>     /dev/mapper/userluks   12.00GiB
>
> System,DUP: Size:32.00MiB, Used:160.00KiB (0.49%)
>     /dev/mapper/userluks   64.00MiB
>
> Unallocated:
>     /dev/mapper/userluks    1.47TiB
>
> # btrfs check /dev/mapper/xyz
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/xyz
> UUID: 56cea9cf-5374-4a43-b19d-6b0b143dc635
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> [5/7] checking only csums items (without verifying data)
> [6/7] checking root refs
> [7/7] checking quota groups skipped (not enabled on this FS)
> found 1230187327496 bytes used, no error found

Since btrfs-check reports no error, it means if there is some real
error, it's in data, not metadata.

And since no error message, the only way to catch the problem is through
"btrfs device stats" command to see which device gets is error
accounting increased.

And since the values are accumulated after the creation of the fs, it
may not be that obvious.

So you may want to record the output, run scrub again, then compare the
output to determine which device is affected.


Or, you can use "btrfs check --check-data-csum" to do a "scrub" in user
space.

Thanks,
Qu
> total csum bytes: 1195610680
> total tree bytes: 5648285696
> total fs tree bytes: 4011016192
> total extent tree bytes: 379256832
> btree space waste bytes: 827370015
> file data blocks allocated: 5497457123328
>   referenced 5523039584256
>
> If more info is needed, please let me know. Recommendations and advice
> are appreciated.
> Thank you.
>