linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adam Borowski <kilobyte@angband.pl>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: RAID 6 corrupted
Date: Wed, 17 May 2017 12:15:23 +0200	[thread overview]
Message-ID: <20170517101523.ylmw4qo2wjsnibfh@angband.pl> (raw)
In-Reply-To: <pan$3156f$ad60295$88e5604$e6cc7e68@cox.net>

On Wed, May 17, 2017 at 09:52:28AM +0000, Duncan wrote:
> Łukasz Wróblewski posted on Wed, 17 May 2017 10:27:53 +0200 as excerpted:
> > About two years ago I created RAID 6 consisting of 5 disks with BTRFS.
> > One of the disks has crashed.
> > I started to exchange it for another, but I did something wrong.
> > Or at the time, RAID56 support was experimental in BTRFS.

> > Linux localhost 4.10.12-coreos
> 
> For anything raid56 related, you'll need at /least/ 4.11, as it has some 
> major raid56 stability patch updates.

Uhm, am I missing something?
    git shortlog v4.10..v4.11 -- fs/btrfs/
shows nothing related to RAID5/6 (save for a single commit that removes an
unused variable).

> There's still some issues with raid56, the biggest being that unlike most 
> of btrfs, the parity isn't COW, meaning the traditional parity-raid write 
> hole remains as an issue, a BIG issue for btrfs due to its design, but 
> that's not really fixable without a full raid56 rewrite, so it'll remain 
> the case with the existing raid56 mode likely forever, and a new 
> implementation that COWs parity as well may eventually happen.

Ideas like plug extents (real or virtual) would fix this without a format
change.  In fact, I don't see how a format change would help: there's no way
around having every stripe belong to exactly 0 or 1 transactions, as
otherwise it's RMW rather than COW.  That'd require some auto reclaim, but
reclaim in general sounds like a thing we want, with recent research knorrie
did about SSD.

Well, there's RAIDz, but that's no RAID5 but a hybrid between that and
RAID1, and it doesn't play well with btrfs' concept of block groups.

> But the patches that went into 4.11 fix the known existing issues other 
> than the usual write hole, and they're effectively mandatory for any 
> attempt at repair or recovery of existing raid56 once there are issues of 
> any sort.  They're not a guarantee of a fix, but before that, any attempt 
> at a fix has a rather good chance of making the problem worse instead of 
> better, so you really do want 4.11 if you're doing btrfs raid56 at all.

If you mean 4.12-rc1, then yeah, these patches are a big step forward.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

  parent reply	other threads:[~2017-05-17 10:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17  8:27 RAID 6 corrupted Łukasz Wróblewski
2017-05-17  9:45 ` Adam Borowski
2017-05-17  9:52 ` Duncan
2017-05-17 10:05   ` Duncan
2017-05-17 10:15   ` Adam Borowski [this message]
2017-05-18  2:09     ` Łukasz Wróblewski
2017-05-18  3:29       ` Adam Borowski
2017-05-18  6:08         ` Duncan
2017-05-18  8:34           ` Adam Borowski
2017-05-18  5:17       ` Roman Mamedov
2017-05-18  6:12         ` Duncan
2017-05-19  8:55           ` Pasi Kärkkäinen
2017-05-19  9:09             ` Roman Mamedov
2017-05-20  2:30             ` Duncan

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=20170517101523.ylmw4qo2wjsnibfh@angband.pl \
    --to=kilobyte@angband.pl \
    --cc=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).