All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Repair broken btrfs raid6?
Date: Tue, 10 Feb 2015 03:36:14 +0000 (UTC)	[thread overview]
Message-ID: <pan$cda6d$176f5270$fba14a89$4e5f5430@cox.net> (raw)
In-Reply-To: CAGwxe4gXPEOTPfNc2=0E0HAfDfTRKRcqqPjVJimbWJr5riz4DA@mail.gmail.com

Tobias Holst posted on Mon, 09 Feb 2015 23:45:21 +0100 as excerpted:

> So a short summary:
> - btrfs raid6 on 3.19.0 with btrfs-progs 3.19-rc2
> - does not mount at boot up, "open_ctree failed" (disk 3)
> - mounts successfully after bootup
> - randomly "checksum verify failed" (disk 5)
> - balance and scrub crash after some time
> - after a while the volume gets unreadable, saying "parent transid
> verify failed" (disk 4 or 5)
> 
> And it looks like there still is no way to btrfsck a raid6.
> 
> Any ideas how to repair this filesystem?

(As a btrfs user/sysadmin and a list regular, not a dev, and not yet 
brave enough to try raid5/6 modes here...)

Btrfs raid6 should indeed be generally working in 3.19, including repair, 
yes.  Certainly, it's much closer to working than anything previous.

However, that code, while it actually exists now and is I believe in 
theory complete, is still very VERY new, and thus, it can be expected to 
be still quite buggy.  I've been telling people not to expect it to 
actually work for another kernel cycle (3.20), and even then, don't 
expect it to be as stable as the raid0/1/10 code, which after all has 
been in actual use for (well) over a year now, and thus has had a chance 
to have even many of the the not immediately obvious bugs show up and get 
worked out.  That'll take several more kernel cycles -- I've been 
suggesting that people not consider the raid56 code as stable as the 
earlier raid forms for another two cycles (3.22) at least.

HOWEVER, without claiming to speak for the devs working on it themselves, 
now that the code is actually there and it's time to start exterminating 
bugs in it, I expect they'll be very interested in your bug report, and 
if you're prepared to spend the time working thru it with them, applying 
patches, etc, you could well find your bugs fixed and be back operational 
before 3.20 or whatever. =:^)

Meanwhile, there's actually an integration branch with even newer code 
that hasn't hit release yet.  Given the still very new state of the 
btrfs56 mode code, if you're already brave enough to be running raid6 
mode and are having problems, your chances with integration are likely to 
be even better than with current release.  Of course it could break 
things worse too, but if you're already running raid56 mode I guess 
you're already prepared for that, and are either testing with throw-away 
data or data that's already well backed up, such that you're prepared to 
lose the btrfs raid6 copy of it in any case, so you might as well try 
integration...

See the wiki or other posts for the integration branch repos.  (As I said 
above I'm not brave enough to try raid56 yet, nor have I tried 
integration, so I don't have the links handy.)

-- 
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:[~2015-02-10  3:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-09 22:45 Repair broken btrfs raid6? Tobias Holst
2015-02-10  3:36 ` Duncan [this message]
2015-02-10  7:17 ` Kai Krakow
2015-02-10 13:15   ` Ed Tomlinson
2015-02-13  1:12     ` Kai Krakow
2015-02-10 18:18   ` Tobias Holst
2015-02-11 14:46 ` Tobias Holst
2015-02-12  9:16   ` Liu Bo
2015-02-12 23:22     ` Tobias Holst
2015-02-13  8:06       ` Liu Bo
2015-02-13 18:26         ` Tobias Holst
2015-02-13 21:54           ` Tobias Holst
2015-02-15  3:30             ` Liu Bo
2015-02-15 20:45               ` Tobias Holst

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$cda6d$176f5270$fba14a89$4e5f5430@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.