linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).