Re: Scrub problem with Debian kernel 6.12.33+deb13-amd64

[Nicholas D Steeves <sten@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]

Qu Wenruo <quwenruo.btrfs@gmx.com> writes:

> 在 2025/7/7 20:25, Russell Coker 写道:
>> I ran a scrub on my laptop running the latest Debian/Testing setup.  It's a
>> Thinkpad X1 Carbon Gen6 that has just been updated to the latest firmware
>> (Thinkpad BIOS, management engine, and some 3rd thing on the motherboard).  It
>> had crashed a few times before which I think has been fixed by the firmware
>> update, it is plausible that the crashes caused some corruption.
>
> You miss the most important thing, kernel version.

Well, it was in the subject line (6.12.33, Debian revision 13), but
I agree that it's best to put it in both places.

>> The system is running LUKS encryption.  After the monthly btrfs scrub I got
>> the following in the cron output:
>> 
>> ERROR: there are 1 uncorrectable errors
>> Starting scrub on devid 1
>> scrub done for d90583c8-9284-48b4-9444-abd00924002a
>> Scrub started:    Mon Jul  7 02:30:01 2025
>> Status:           finished
>> Duration:         0:02:46
>> Total to scrub:   226.35GiB
>> Rate:             1.36GiB/s
>> Error summary:    csum=110693
>>    Corrected:      0
>>    Uncorrectable:  110693
>>    Unverified:     0
>> 
>> I ran the following commands to get more data and got the below output.  It
>> seems that we have a clear problem of btrfs dev sta reporting 0 errors when
>> there were apparently many errors!

Russell, was this bug reported in Debian?  Imho this one is kind of a
big deal when we're at the release candidate stage.  Please feel free to
add me to the X-Debbugs-Cc pseudoheader if/when you report btrfs-related
Debian bugs in the future.  Also, since I seem to remember that you're
excellent at finding and reporting bugs, maybe you'd like to co-found a
btrfs-enablement team?

> Already fixed by upstream commit ec1f3a207cdf ("btrfs: scrub: update 
> device stats when an error is detected").

Which is 5bd799d2 on the linux-6.12.y branch, and is first present in
v6.12.34, so Debian 13 (trixie) is no longer affected; however, trixie
was affected when Russell reported this issue.

[snip]

>> ERROR: there are 1 uncorrectable errors
>> 
>> Below are the kernel messages.  No mentions of files or directories so the
>> scrub doesn't seem to be doing it's job well here.  It should either fix
>> things or tell me what rm command I can use to replace things that can't be
>> fixed!
>
>
>  > Jul 07 20:47:20 dojacat kernel: scrub_stripe_report_errors: 7117 
> callbacks suppressed
>
> Thus the output of file path may be rate limited.
>
> And dmesg is not the best way to tell end users where the corruption is, 
> furthermore there are a lot of valid reasons that a path can not be 
> resolved (already orphan, belongs to a tree block etc).

I agree!

> Although I believe you're right that btrfs should have a reliable way to 
> indicate which files are affected, but we do not want to populate the 
> dmesg without any limit either.
>
> In the future we may have a better solution, but for now the best 
> solution would be using the logical bytenr e.g. 327893450752, and pass 
> it into `btrfs ins logical-resolve` to do the path resolve.

Are logical bytenr numbers stored anywhere outside of the kernel log?  I
hope they're stored in filesystem metadata :)

Regards,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]