All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.