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