Re: btrfs send yields "ERROR: send ioctl failed with -5: Input/output error"

[Chris Murphy <lists@colorremedies.com>]

On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler <y2k@y2kbugger.com> wrote:

> I will gladly repeat this process, but I am very concerned why this
> corruption happened in the first place.

Right. So everyone who can, needs to run the three scrubs on all
available Btrfs volumes/devices and see if they get any discrepancies.
I only ever use the online scrub so I have no idea if --offline or the
older check --check-data-csum differ from it.

scrub start
scrub start --offline
btrfs check --check-data-csum

I think you've hit a software bug if those three methods don't exactly
agree with each other. And it's a question which one is correct, or if
they all have different bugs in them?



>
> More tests:
>
> scrub start --offline
>     All devices had errors in differing amounts
>     I will verify that these counts are repeatable.
>     Csum error: 150
>     Csum error: 238
>     Csum error: 175
>
> btrfs check
>     found 2179745955840 bytes used, no error found
>
> btrfs check --check-data-csum
>     mirror 0 bytenr 13348855808 csum 2387937020 expected csum 562782116
>     mirror 0 bytenr 23398821888 csum 3602081170 expected csum 1963854755


Offhand that sounds like three different results, which is sorta fakaked.


>     ...
>
> The only thing I could think of is that the btrfs version that I used to mkfs
> was not up to date. Is there a way to determine which version was used to
> create the filesystem?

That information isn't in the superblock. I think it could be added to
the device tree as a PERSISTENT_ITEM, although I'm not sure how useful
it is.

Anyway, I don't think it's related. mkfs.btrfs writes a tiny amount to
the drive, and almost certainly the problem is happening later.



-- 
Chris Murphy