From: Zak Kohler <y2k@y2kbugger.com>
To: btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs send yields "ERROR: send ioctl failed with -5: Input/output error"
Date: Thu, 2 Nov 2017 08:23:49 -0400 [thread overview]
Message-ID: <CAD8FQQ2hZ_6t6FD1ELBXjczwaodggvYwKe630QNuPMB_DvDwig@mail.gmail.com> (raw)
In-Reply-To: <pan$684ae$1b07c469$c5218ba1$a89f7997@cox.net>
Well it looks like things have stabilized....for the
moment at least.
$ btrfs scrub start --offline --progress /dev/disk/by-id/XX3
Doing offline scrub [o] [681/681]
Scrub result:
Tree bytes scrubbed: 5234425856
Tree extents scrubbed: 638968
Data bytes scrubbed: 4353724284928
Data extents scrubbed: 374300
Data bytes without csum: 533200896
Read error: 0
Verify error: 0
Csum error: 0
$ sudo btrfs scrub start --offline --progress /dev/disk/by-id/XX3
Doing offline scrub [o] [681/681]
Scrub result:
Tree bytes scrubbed: 5234425856
Tree extents scrubbed: 638968
Data bytes scrubbed: 4353724284928
Data extents scrubbed: 374300
Data bytes without csum: 533200896
Read error: 0
Verify error: 0
Csum error: 0
$ sudo btrfs send /mnt/dataroot.2017.10.21 | pv -i2 > /dev/null
At subvol /mnt/dataroot.2017.10.21
1.55TiB 1:38:46 [ 283MiB/s] [ <=> ]
One interesting note is that when the --offline scrub came back with
Csum errors, sometimes the Tree bytes scrubbed were different:
Tree bytes scrubbed: 5234491392 #bad
vs
Tree bytes scrubbed: 5234425856 #good
The hardware is a Q6600 (the first Core2 Quad @2.4GHz) and a dell PERC
6/i card flashed with IT mode.
*** 2 days have past since I wrote the above
I checked my overclock and sure enough I had the FSB boosted, CPU
reaching ~2.9 GHz. The PCI were held at a constant freq but I bet
there was some bad interaction with the PERC. I don't know why the
system chose to be stable 2 days ago before resetting the overclock,
but I am very confident it will stay that way now.
Takeaways:
1. I came to btrfs because upon manual hash comparison I noticed bit
flips occurring. Now I have very likely found the source of the issues
thanks to btrfs and I can also be more confident against those issues
in the future.
2. A stable memtest86+ doesn't necessarily mean a stable storage stack
next prev parent reply other threads:[~2017-11-02 12:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-23 4:25 btrfs send yields "ERROR: send ioctl failed with -5: Input/output error" Zak Kohler
2017-10-24 0:23 ` Zak Kohler
2017-10-24 4:52 ` Lakshmipathi.G
2017-10-24 6:00 ` Zak Kohler
2017-10-25 1:52 ` Zak Kohler
2017-10-25 3:43 ` Lakshmipathi.G
2017-10-26 2:34 ` Zak Kohler
2017-10-29 19:05 ` Chris Murphy
2017-10-30 1:57 ` Zak Kohler
2017-10-30 4:09 ` Duncan
2017-10-30 14:36 ` Zak Kohler
2017-10-31 2:33 ` Duncan
2017-11-02 12:23 ` Zak Kohler [this message]
2017-10-30 18:52 ` Chris Murphy
2017-11-06 20:04 ` Chris Murphy
[not found] ` <CAD8FQQ3XSsLt4XYdeMg7r3oX9WUerW27f8RMuKurjL4cpY8=1g@mail.gmail.com>
2017-11-11 19:11 ` Chris Murphy
2017-10-30 4:07 ` Lakshmipathi.G
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD8FQQ2hZ_6t6FD1ELBXjczwaodggvYwKe630QNuPMB_DvDwig@mail.gmail.com \
--to=y2k@y2kbugger.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).