From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: The performance is not as expected when used several disks on raid0.
Date: Tue, 18 Aug 2015 07:34:09 -0400 [thread overview]
Message-ID: <55D31831.1000404@gmail.com> (raw)
In-Reply-To: <pan$9af23$4fb7d57c$d76038f$6f4281af@cox.net>
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]
On 2015-08-17 19:06, Duncan wrote:
> Austin S Hemmelgarn posted on Mon, 17 Aug 2015 07:38:13 -0400 as
> excerpted:
>
>> I've also found that BTRFS raid5/6 on top of MD RAID0 mitigates (to a
>> certain extent that is) the performance penalty of doing raid5/6 if you
>> aren't on ridiculously fast storage, probably not something that should
>> be used in production yet, but it's how I've got the near-line backups
>> setup on my home server system.
>
> As should be clear from my previous posts on the subject, I'm
> conservative enough not to be comfortable with the btrfs raid56
> implementation yet. My recommendation has been, and remains, unless
> you're deliberately testing it in ordered to help find/report/workout
> bugs, give it a year after the nominally full implementation (3.19, so
> until 4.4), before expecting it to be reasonably as stable as the rest of
> btrfs (which itself isn't fully stable yet).
>
> But the almost-released 4.2 does seem to be past the initial nominally
> btrfs raid56 full-code bugs, and I'd call an intermediate level backup,
> with working copies in front and itself backed up in back, a reasonable
> first working (as opposed to testing) deployment.
Yeah, I've been ridiculously luck to have not hit _any_ of the raid56
related bugs. In fact the only issue I've had with it was a result of a
btrfs interaction with dm-thinp (if dm-thinp isn't set to zero newly
allocated blocks, btrfs sometimes loses it's mind during remount, which
in turn reminds me that I meant to check if this was fixed or not).
And the deployment you suggest is ironically how I use it, I've got my
root filesystem on btrfs raid1 across 2 SSD's, with a btrfs raid6 on top
of LVM single volumes on a set of 4 1TB HDD's as a target for receive
(and configured such that I can directly boot any of the backups there),
and then store compressed, encrypted tarballs of the Sunday backups on 3
different cloud storage services and an external 4TB HDD (It's wonderful
how Gentoo lends itself so well to custom solutions).
>
> And yes, btrfs raid5/6 over mdraid0 would have the same general
> complementary nature as btrfs raid1/10 over mdraid0.
>
>> It may also be worth pointing out that
>> BTRFS raid6 lets you use 4 disks minimum, as opposed to most other raid6
>> implementations that (unnecessarily, as a 4 disk RAID6 is not a
>> degenerate form) require 5.
>
> 4-device raid6, btrfs and mdraid both allow that, good point. But of
> course mdraid6 doesn't have the data integrity, only rebuild-parity.
>
Huh, I didn't know that mdraid allowed that, I know dm-raid through LVM
doesn't (which in turn is a large part of what caused me to try btrfs
raid56 so soon, I had been going to do btrfs raid1 on top of LVM based
raid6).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-08-18 11:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 15:16 The performance is not as expected when used several disks on raid0 Eduardo Bach
2015-08-14 16:30 ` Calvin Walton
2015-08-14 16:35 ` Calvin Walton
2015-08-17 19:44 ` Eduardo Bach
2015-08-17 20:36 ` Calvin Walton
2015-08-14 18:31 ` Chris Murphy
2015-08-14 19:50 ` Austin S Hemmelgarn
2015-08-14 19:54 ` Chris Murphy
2015-08-14 19:58 ` Austin S Hemmelgarn
2015-08-15 6:30 ` Duncan
2015-08-17 11:38 ` Austin S Hemmelgarn
2015-08-17 23:06 ` Duncan
2015-08-18 11:34 ` Austin S Hemmelgarn [this message]
2015-08-18 14:59 ` Duncan
2015-08-17 19:57 ` Eduardo Bach
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=55D31831.1000404@gmail.com \
--to=ahferroin7@gmail.com \
--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