RE: BTRFS checksum mismatch - false positives

[<hoegge@gmail.com>]

Hi Chris

uname:
Linux MHPNAS 3.10.105 #24922 SMP Wed Jul 3 16:37:24 CST 2019 x86_64 GNU/Linux synology_avoton_1815+

btrfs --version                                                                                            
btrfs-progs v4.0

ash-4.3# btrfs device stats .                                                                                                                                                                                                               
[/dev/mapper/vg1-volume_1].write_io_errs   0
[/dev/mapper/vg1-volume_1].read_io_errs    0
[/dev/mapper/vg1-volume_1].flush_io_errs   0
[/dev/mapper/vg1-volume_1].corruption_errs 1014
[/dev/mapper/vg1-volume_1].generation_errs 0

Concerning self healing? Synology run BTRFS on top of their SHR - which means, this where there is redundancy (like RAID5 / RAID6). I don't think they use any BTRFS RAID  (likely due to the RAID5/6 issues with BTRFS). Does that then mean, there is no redundancy / self-healing available for data? 

How would you like the log files - in private mail. I assume it is the kern.log. To make them useful, I suppose I should also pinpoint which files seem to be intact?

I gather it is the "BTRFS: (null) at logical ... " line that indicate mismatch errors ? Not sure why the state "(null"). Like:

2019-09-22T16:52:09+02:00 MHPNAS kernel: [1208505.999676] BTRFS: (null) at logical 1123177283584 on dev /dev/vg1/volume_1, sector 2246150816, root 259, inode 305979, offset 1316306944, length 4096, links 1 (path: Backup/Virtual Machines/Kan slettes/Smaller Clone of Windows 7 x64 for win 10 upgrade.vmwarevm/Windows 7 x64-cl1.vmdk)

Best
Hoegge

-----Original Message-----
From: Chris Murphy <lists@colorremedies.com> 
Sent: 2019-09-23 21:12
To: hoegge@gmail.com
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS checksum mismatch - false positives

On Mon, Sep 23, 2019 at 12:19 PM <hoegge@gmail.com> wrote:
>
> Dear BTRFS mailing list,
>
> I'm running BTRFS on my Synology Diskstation and they have referred me 
> to the BTRFS developers.

If it's a generic question that's fine, but all the development happening on this list is very recent kernels and btrfs-progs, which is not typically the case with distribution specific products.

>
> For a while I have had quite a few (tens - not hundreds) checksum 
> mismatch errors on my device (around 6 TB data). It runs BTRFS on SHR 
> (Synology Hybrid Raid). Most of these checksum mismatches, though, do not seem "real".
> Most of the files are identical to the original files (checked by 
> binary comparison and by recalculated MD5 hashes).
>
> What can explain that problem? I thought BTRFS only reported checksum 
> mismatch errors, when it cannot self-heal the files?

It'll report them in any case, and also report if they're fixed. There are different checksum errors depending on whether metadata or data are affected (both are checksummed). Btrfs can only self-heal with redundant copies available. By default metadata is duplicated and should be able to self-heal, but data is not redundant by default. So it'd depend on how the storage stack layout is created.

We need logs though. It's better to have more than less, if you can go back ~5 minutes from the first report of checksum mismatch error, that's better than too aggressive log trimming. Also possibly useful:

# uname -a
# btrfs --version


--
Chris Murphy