Re: csum failed during copy/compare

[Chris Murphy <lists@colorremedies.com>]

On Fri, Oct 21, 2016 at 7:19 AM, Martin Dev <mrturtledev@gmail.com> wrote:
> SATA trace shows device behaving correctly.
> btrfs repair --ignore-errors /dev/sda2 /tmp/ will yield files that are
> not verifiable by FIO, and differ from the original files on the
> internal drive that they were copied from at the failing offset.

Did you try without discard mount option? And did you get different results?

I'm not following 'btrfs repair --ignore-errors /dev/sda2 /tmp/'  at
all. Is this actually restore?

I'm not an expert in this particular area of finding problems as
they're being written - but it sounds like that's what's going on in
your case - since kernel messages are currently not revealing at all,
all I can think of is to build a kernel.org kernel, I think for what
you're doing it's fine to use 4.4.26 but it might get more traction to
use 4.9.rc1 just because that's what's currently being worked on and
likely where any fix would have to go first before it got backported.
If it's a bug. And I'd build with these:

CONFIG_BTRFS_FS_CHECK_INTEGRITY=y
CONFIG_BTRFS_DEBUG=y

The first does nothing unless you use one of two possible mount
options check_int and check_int_data.
https://btrfs.wiki.kernel.org/index.php/Mount_options

I don't have any advice on how to test. Maybe leave out the check
integrity mount options for the first round and see if you can still
trigger the problem, since there are already two major changes: a.)
it's a kernel.org kernel and b.) it has debug enabled. If you can
trigger the problem but it's still not revealing then test with
check_int which has less performance impact than check_int_data. It
looks like what you're getting is a metadata inconsistency but I'm not
certain.

-- 
Chris Murphy