From: "Jérôme Carretero" <cJ-ko@zougloub.eu>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Issues while doing btrfs delete missing in raid6
Date: Mon, 20 Nov 2017 20:06:35 -0500 [thread overview]
Message-ID: <20171120200635.01578103@Vantage.cJ> (raw)
In-Reply-To: <pan$5ba16$591e9570$7efd0d56$66c0e056@cox.net>
Hi Duncan,
On Mon, 20 Nov 2017 21:57:47 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Jérôme Carretero posted on Mon, 20 Nov 2017 01:43:44 -0500 as
> excerpted:
>
> > While doing a test (to evaluate drives), where I'm filling a bunch
> > of drives in RAID6, one of the disks failed in the process.
> > (System with v4.14 / ECC).
>
> FWIW, see raid56 status in the status page (table and below raid56
> note).
>
> https://btrfs.wiki.kernel.org/index.php/Status
>
> Basically, after the fixes in 4.12, it mostly works as long as things
> don't go too badly wrong, but due to the write hole and corner cases
> such as the checksum repair failure you ran into, it's not something
> people on this list can in good conscience recommend for general use,
> because it simply lacks the reliability people tend to want raid56
> for, at least in combination with the file-integrity/checksumming
> features btrfs may be chosen for. The two together simply aren't as
> reliable as the separate features might imply they should be, and
> there are known to be better alternatives.
>
> Unfortunately that's likely to remain the case for awhile due to the
> complexity of a real fix, despite the 4.12 fixes to the worst of the
> problems.
>
> One reasonably performant and reliable alternative, tho it's more
> directly an alternative to btrfs raid10, where it's better performing
> due to btrfs raid10 not yet being performance optimized, is btrfs
> raid1 on top of two raid0s (mdraid0, for instance).
I normally use btrfs RAID1, but wanted to see what's new with RAID6
while "priming" some new disks. There was some click-bait on Phoronix,
the wiki page (status or https://btrfs.wiki.kernel.org/index.php/RAID56)
didn't look very up-to-date and quite vague, and not so many horror
stories on LKML...
Anyway, this was a 200-hour experiment, and apart from the failure, the
speed was low, really far from RAID1 (and there was plenty of CPU left
to compute parity), and "delete missing" was unexpectedly slow, running
at perhaps 10 MB/s average.
TL;DR: As of v4.14 RAID6 is as reliable as RAID0, but slower =)
--
Jérôme
prev parent reply other threads:[~2017-11-21 1:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 6:43 Issues while doing btrfs delete missing in raid6 Jérôme Carretero
2017-11-20 6:54 ` Jérôme Carretero
2017-11-20 7:13 ` Qu Wenruo
2017-11-20 21:57 ` Duncan
2017-11-21 1:06 ` Jérôme Carretero [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=20171120200635.01578103@Vantage.cJ \
--to=cj-ko@zougloub.eu \
--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).