Re: question to btrfs scrub

[Qu Wenruo <wqu@suse.com>]

On 2023/7/8 04:54, Bernd Lentes wrote:
>> -----Original Message-----
>> From: Qu Wenruo <quwenruo.btrfs@gmx.com>
>> Sent: Thursday, July 6, 2023 8:23 AM
>> To: Remi Gauvin <remi@georgianit.com>; Bernd Lentes
>> <bernd.lentes@helmholtz-muenchen.de>; Qu Wenruo <wqu@suse.com>;
>> linux-btrfs <linux-btrfs@vger.kernel.org>
>> Subject: Re: question to btrfs scrub
> 
> 
>> 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.
> 
> The server we are talking about is still in testing, not in production.
> That means we can change the config.
> Should we take RAID1 into account ?

Personally speaking, with your hardware I already believe it's not 
hardware causing the corruption.

But it can be extra safe if you go RAID1 for data, and re-test the workload.

If the corruption still happens, it's almost sure it's btrfs to blame.

Thanks,
Qu
> We have enough disk space.
> 
> Bernd
> 
> Helmholtz Zentrum München – Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
> Ingolstädter Landstraße 1, D-85764 Neuherberg, https://www.helmholtz-munich.de
> Geschäftsführung: Prof. Dr. med. Dr. h.c. Matthias Tschöp, Daniela Sommer (komm.) | Aufsichtsratsvorsitzende: MinDir’in Prof. Dr. Veronika von Messling
> Registergericht: Amtsgericht München HRB 6466 | USt-IdNr. DE 129521671