Re: Critical error from Tree-checker

[Archange <archange@archlinux.org>]

Le 12/09/2024 à 01:23, Qu Wenruo a écrit :
>
>
> 在 2024/9/12 06:50, Archange 写道:
>> Le 12/09/2024 à 00:54, Qu Wenruo a écrit :
>>> 在 2024/9/12 05:25, Archange 写道:
>>>> Le 11/09/2024 à 01:37, Qu Wenruo a écrit :
>>>>> 在 2024/9/11 06:58, Qu Wenruo 写道:
>>>>>> 在 2024/9/11 06:35, Archange 写道:
>>>>>> […]
>>> […]
>>>
>>> That being said no critical error has been encountered since I’ve 
>>> had to
>>> repair my boot, but I’ve not tried to scrub from the running system
>>> again, should I do that (as it used to trigger the error before)?
>
> Please do a `btrfs check` to make sure everything is fine.

While the previous one (see my second message in this thread) had no 
error, there is now one:

# btrfs check /dev/mapper/rootext
Opening filesystem to check...
Checking filesystem on /dev/mapper/rootext
UUID: e6614f01-6f56-4776-8b0a-c260089c35e7
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
wanted bytes 688128, found 720896 for off 676326604800
cache appears valid but isn't 676326604800
[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 478434086912 bytes used, error(s) found
total csum bytes: 465136176
total tree bytes: 1590493184
total fs tree bytes: 870760448
total extent tree bytes: 138231808
btree space waste bytes: 326062620
file data blocks allocated: 516090466304
  referenced 492383629312

> For the bad free space cache, I'd recommend to go v2 space cache instead.

Since the above error seems related to space cache, and that I had 
switching to v2 on my todo list for a long time, I’ve just did so.

dmesg mount messages right after (nothing unexpected I guess, outside 
the warning and “corrupt 4” still present):

[  812.242212] BTRFS: device label root devid 1 transid 6065207 
/dev/mapper/rootext (254:1) scanned by mount (2145)
[  812.243727] BTRFS info (device dm-1): first mount of filesystem 
e6614f01-6f56-4776-8b0a-c260089c35e7
[  812.243770] BTRFS info (device dm-1): using crc32c (crc32c-intel) 
checksum algorithm
[  812.243788] BTRFS info (device dm-1): using free-space-tree
[  812.256356] BTRFS warning (device dm-1): devid 1 physical 0 len 
4194304 inside the reserved space
[  812.258504] BTRFS info (device dm-1): bdev /dev/mapper/rootext errs: 
wr 0, rd 0, flush 0, corrupt 4, gen 0
[  812.810623] BTRFS info (device dm-1): creating free space tree
[  819.778945] BTRFS info (device dm-1): setting compat-ro feature flag 
for FREE_SPACE_TREE (0x1)
[  819.778949] BTRFS info (device dm-1): setting compat-ro feature flag 
for FREE_SPACE_TREE_VALID (0x2)
[  819.877973] BTRFS info (device dm-1): cleaning free space cache v1
[  819.885829] BTRFS info (device dm-1): checking UUID tree
[  866.299565] BTRFS info (device dm-1): last unmount of filesystem 
e6614f01-6f56-4776-8b0a-c260089c35e7

I’ve run check again after that:

# btrfs check /dev/mapper/rootext
Opening filesystem to check...
Checking filesystem on /dev/mapper/rootext
UUID: e6614f01-6f56-4776-8b0a-c260089c35e7
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
there is no free space entry for 0-65536
cache appears valid but isn't 0
[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 478312665088 bytes used, error(s) found
total csum bytes: 465136176
total tree bytes: 1593524224
total fs tree bytes: 870760448
total extent tree bytes: 138231808
btree space waste bytes: 326060271
file data blocks allocated: 515966013440
  referenced 492259176448

So there is still an error, but different this time.