From: Hugo Mills <hugo@carfax.org.uk>
To: George Duffield <forumscollective@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Understanding BTRFS storage
Date: Wed, 26 Aug 2015 11:50:10 +0000 [thread overview]
Message-ID: <20150826115010.GC23769@carfax.org.uk> (raw)
In-Reply-To: <CAG__1a4T=d_O49CnOw+0gtKr56xtrmcjRcmujtUff_s_-oL0Jw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
On Wed, Aug 26, 2015 at 10:56:03AM +0200, George Duffield wrote:
> Hi
>
> Is there a more comprehensive discussion/ documentation of Btrfs
> features than is referenced in
> https://btrfs.wiki.kernel.org/index.php/Main_Page...I'd love to learn
> more but it seems there's no readily available authoritative
> documentation out there?
>
> I'm looking to switch from a 5x3TB mdadm raid5 array to a Btrfs based
> solution that will involve duplicating a data store on a second
> machine for backup purposes (the machine is only powered up for
> backups).
>
> Two quick questions:
> - If I were simply to create a Btrfs volume using 5x3TB drives and not
> create a raid5/6/10 array I understand data would be striped across
> the 5 drives with no reduncancy ... i.e. if a drive fails all data is
> lost? Is this correct?
With RAID-1 metadata and single data, when you lose a device the FS
will continue to be usable. Any data that was stored on the missing
device will return an I/O error when you try to read it. With single
data, the data space is assigned to devices in 1 GiB chunks in
turn. Within that, files that are written once and not modified are
likely to be placed linearly within that sequence. Files that get
modified may have their modifications placed out of sequence on other
chunks and devices.
> - Is Btrfs RAID10 (for data) ready to be used reliably?
I'd say yes, others may say no. I'd suggest using RAID-1 for now
anyway -- it uses the space better when you come to add new devices or
replace them (with different sizes).
Hugo.
--
Hugo Mills | Preventing talpidian orogenesis.
hugo@... carfax.org.uk |
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2015-08-26 11:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 8:56 Understanding BTRFS storage George Duffield
2015-08-26 11:41 ` Austin S Hemmelgarn
2015-08-26 11:50 ` Hugo Mills [this message]
2015-08-26 11:50 ` Roman Mamedov
2015-08-26 12:03 ` Austin S Hemmelgarn
2015-08-27 2:58 ` Duncan
2015-08-27 12:01 ` Austin S Hemmelgarn
2015-08-28 9:47 ` Duncan
2015-08-28 12:54 ` Austin S Hemmelgarn
2015-08-28 8:50 ` George Duffield
2015-08-28 9:35 ` Hugo Mills
2015-08-28 15:42 ` Chris Murphy
2015-08-28 17:11 ` Austin S Hemmelgarn
2015-08-29 8:52 ` George Duffield
2015-08-29 22:28 ` Chris Murphy
2015-09-02 5:01 ` Russell Coker
2015-08-28 9:46 ` Roman Mamedov
2015-08-26 11:50 ` Duncan
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=20150826115010.GC23769@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=forumscollective@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).