linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Hérikz Nawarro" <herikz.nawarro@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs raid assurance
Date: Tue, 25 Jul 2017 09:16:50 -0400	[thread overview]
Message-ID: <32bd5570-7bb4-8234-5e2e-b4ea9ff04ccd@gmail.com> (raw)
In-Reply-To: <CAD6NJSxuix4N=kPbQ_=QRnKP4Ny6kLyVyEA4p=PvBfgtbwrUHw@mail.gmail.com>

On 2017-07-25 08:55, Hérikz Nawarro wrote:
> Hello everyone,
> 
> I'm migrating to btrfs and i would like to know, in a btrfs filesystem
> with 4 disks (multiple sizes) with -d raid0 & -m raid1, how many
> drives can i lost without losing the entire array?
Exactly one, but you will lose data if you lose one device.  Most of the 
BTRFS profiles are poorly named (single and dup being the exceptions), 
and do not behave consistently with the RAID levels they are named 
after.  BTRFS raid1 mode is functionally equivalent to MD or LVM RAID10 
mode, just with larger blocks.  It only gives you two copies of the 
data, so losing one device will make the array degraded, and two will 
effectively nuke it.

If you care about data safety, I would advise against using raid0 for 
data.  If you lose _one_ device in raid0 mode, you will usually lose 
part of most of the files on the volume.  Single mode for data will 
still distribute things evenly and will not have that issue (unless you 
have files larger than 1GB, a file will either be all there or all gone, 
as opposed to having read errors part way through), and isn't much worse 
in terms of performance (BTRFS does not parallelize device access as 
well as it should).

If you care about both performance and data safety, and can tolerate 
having only half the usable space, I would actually suggest running 
BTRFS with both data and metadata in raid1 mode on top of two LVM or MD 
RAID0 volumes.  This should outperform the configuration you listed by a 
significant amount, will provide better data safety, and should also do 
a better job of distributing the load across devices.

  reply	other threads:[~2017-07-25 13:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-25 12:55 btrfs raid assurance Hérikz Nawarro
2017-07-25 13:16 ` Austin S. Hemmelgarn [this message]
2017-07-25 13:46 ` Hugo Mills
2017-07-25 13:50   ` Hérikz Nawarro
2017-07-25 13:51   ` Hugo Mills
2017-07-25 13:55     ` Hérikz Nawarro
2017-07-25 13:58       ` Hugo Mills
2017-07-25 21:29         ` waxhead
2017-07-25 21:45           ` Hugo Mills
2017-07-26 12:12             ` Austin S. Hemmelgarn
2017-07-26 12:27               ` Hugo Mills
2017-07-26 12:28                 ` Hugo Mills
2017-07-26 12:36                 ` Austin S. Hemmelgarn
2017-07-26 23:07                   ` Hugo Mills

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=32bd5570-7bb4-8234-5e2e-b4ea9ff04ccd@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=herikz.nawarro@gmail.com \
    --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).