Duncan wrote:
waxhead posted on Fri, 02 Nov 2018 20:54:40 +0100 as excerpted:
Note that I tend to interpret the btrfs de st / output as if the error
was NOT fixed even if (seems clearly that) it was, so I think the output
is a bit misleading... just saying...
See the btrfs-device manpage, stats subcommand, -z|--reset option, and
device stats section:
-z|--reset
Print the stats and reset the values to zero afterwards.
DEVICE STATS
The device stats keep persistent record of several error classes related
to doing IO. The current values are printed at mount time and
updated during filesystem lifetime or from a scrub run.
So stats keeps a count of historic errors and is only reset when you
specifically reset it, *NOT* when the error is fixed.
Yes, I am perfectly aware of all that. The issue I have is that the
manpage describes corruption errors as "A block checksum mismatched or
corrupted metadata header was found". This does not tell me if this was
a permanent corruption or if it was fixed. That is why I think the
output is a bit misleadning (and I should have said that more clearly).
My point being that btrfs device stats /mnt would have been a lot easier
to read and understand if it distinguished between permanent corruption
e.g. unfixable errors vs fixed errors.
(There's actually a recent patch, I believe in the current dev kernel
4.20/5.0, that will reset a device's stats automatically for the btrfs
replace case when it's actually a different device afterward anyway.
Apparently, it doesn't even do /that/ automatically yet. Keep that in
mind if you replace that device.)
Oh thanks for the heads up, I was under the impression that the device
stats was tracked by btrfs devid, but apparently it is (was) not. Good
to know!
