Re: [6.2][regression] after commit 947a629988f191807d2d22ba63ae18259bb645c5 btrfs volume periodical forced switch to readonly after a lot of disk writes

[Mikhail Gavrilov]

On Mon, Dec 26, 2022 at 8:29 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote:
>
>
> OK, indeed a level mismatch.
>
>  From the remaining lines, it shows we're failing at
> do_free_extent_accounting(), which failed at the btrfs_del_csums().
>
> And inside btrfs_del_csums(), what we do are all regular btree
> operations, thus the tree level check should work without problem.
>
> Thus it seems to be a corrupted csum tree.

Do I need to debug anything else to understand the cause of the error?
Thanks.

> Could you please run "btrfs check --readonly" from a liveCD?
> There are tons of possible false alerts if ran on a RW mounted fs.
>

# btrfs check --readonly /dev/nvme0n1p3
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p3
UUID: 40e0b5d2-df54-46e0-b6f4-2f868296271d
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[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 6828416307200 bytes used, no error found
total csum bytes: 6651838248
total tree bytes: 16378380288
total fs tree bytes: 7483179008
total extent tree bytes: 1228210176
btree space waste bytes: 2413299694
file data blocks allocated: 6899999100928
 referenced 7488299450368
[root@localhost-live ~]#

With liveCD looks like all OK (no errors found).

-- 
Best Regards,
Mike Gavrilov.