Re: question to btrfs scrub

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

On 2023/7/6 01:53, Remi Gauvin wrote:
> On 2023-07-05 11:01 a.m., Bernd Lentes wrote:
>
>>> The main thing here is, nodatacow implies nodatacsum, thus it would not
>>> generate any csum nor verify it.
>>
>> But aren't checksums important in case of errors ?
>> OK. I know which VM images produced checksum errors. I delete them and restore them from the backup.
>> Then I set the attribute for the directory.
>>
>> OK ?
>>
>
> I'm really not sure how we jumped to this being a bug that you should
> work around by disabling Csum.  I know Qu mentioned the possibility (and
> I by no means want to question his expertise.)... But unless I missed
> something in this thread, there has been no real indication to not
> simply take the error at face value,, the drive/controller/usb combo
> resulted in corrupt data, BTRFS detected and reported...
>
> I would hope that the error detection working exactly as it is intended
> would be the most likely explanation.

I hate to point my finger to btrfs itself, but I still remember in the
old days some workload can lead to such false alerts.
But I can not recall which commit is causing and which one is fixing the
problem.

Another concern is, the report is using SINGLE for data, which is
completely fine, but it doesn't help us to determine if it's really a
hardware data corruption or btrfs bugs.

If the report is using RAID1, and those corruption are all repairable,
then we're pretty sure it's data corruption on disk.
Or if all mirrors are corrupted in a RAID1* config, then we know it's
definitely btrfs causing the problem.

But with SINGLE profile, it's really hard to say.

Thanks,
Qu

>
> As for what you can do if that's the case, delete the corrupted file and
> see if it happens again, (in which case, buy more reliable hardware.),
> or just skip the wait and go right to (hopefully) better hardware.
>
>