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 <[email protected]>
Sent: 2019-09-23 21:12
To: [email protected]
Cc: Btrfs BTRFS <[email protected]>
Subject: Re: BTRFS checksum mismatch - false positives
On Mon, Sep 23, 2019 at 12:19 PM <[email protected]> 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
