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.
next prev parent 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).