Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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 --]

  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