From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Scrub not fixing checksum errors on RAID6
Date: Thu, 23 Jun 2016 17:17:19 +0000 (UTC) [thread overview]
Message-ID: <pan$5d677$54ab98f9$6198f8a8$b7bfb187@cox.net> (raw)
In-Reply-To: 0c0d5c8f-af85-6e4d-83b4-e11bb811dc5d@gmail.com
Jussi Kansanen posted on Thu, 23 Jun 2016 18:17:46 +0300 as excerpted:
> Scrub found some checksum errors on my RAID6, errors are said to be
> fixed but every scrub results in identical errors. Any ideas why this is
> happening? The HDD seems to be working OK, no IO errors, no SMART errors
> and it passed SMART long-test.
>
> Latest scrub was run with 4.6.2 kernel & 4.6 btrfs progs. Earlier runs
> where done with 4.5.x & 4.6 with up to date btrfs progs (at the time).
Short non-technical FYI...
Btrfs raid56 mode is unfortunately not yet upto current general btrfs
stability[1]. There are a number of known raid56 mode bugs and reports
such as this that need to be fixed first before it should be considered
generally usable for anything but testing.
It wasn't clear from your post whether you know this and were simply
reporting a problem that appeared in your testing so it can be fixed, or
if you were trying to use raid56 mode for daily use and ran into this
problem as a result. I'm simply saying such issues are to be expected at
this point, and that raid56 mode simply isn't ready for normal use yet,
as there are a number of known problems such as this still around.
Btrfs raid1 mode, and to a slightly lessor extent, raid10 mode, is rather
more mature and considered up to general btrfs stability status. (I'm
using raid1 mode here. Raid10 mode basically works but may be slower
than expected as it's not optimized yet. Btrfs raid1 mode layered on top
of a pair of md/dm-raid0s will likely be faster than btrfs raid10 without
loss of the additional btrfs functionality.)
---
[1] Current general btrfs stability status: Stabilizing, but not yet
fully stable and mature. Keep backups and be prepared for occasional
bugs that may force you to use them, but btrfs can be reasonably used for
daily use provided you are doing so.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
prev parent reply other threads:[~2016-06-23 17:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-23 15:17 Scrub not fixing checksum errors on RAID6 Jussi Kansanen
2016-06-23 17:17 ` Duncan [this message]
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='pan$5d677$54ab98f9$6198f8a8$b7bfb187@cox.net' \
--to=1i5t5.duncan@cox.net \
--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).