From: Hugo Mills <hugo@carfax.org.uk>
To: "Hérikz Nawarro" <herikz.nawarro@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs raid assurance
Date: Tue, 25 Jul 2017 13:46:56 +0000 [thread overview]
Message-ID: <20170725134656.GL7140@carfax.org.uk> (raw)
In-Reply-To: <CAD6NJSxuix4N=kPbQ_=QRnKP4Ny6kLyVyEA4p=PvBfgtbwrUHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
On Tue, Jul 25, 2017 at 09:55:37AM -0300, 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?
You can lose one device in the array, and the FS structure will be
OK -- it will still mount, and you'll be able to see all the filenames
and directory structures and so on.
However, if you do lose one device, then you'll lose
(approximately) half of the bytes in all of your files, most likely in
alternating 64k slices in each file. Attempting to read the missing
parts will result in I/O errors being returned from the filesystem.
So, while the FS is in theory still fine as a (probably read-only)
filesystem, it's actually going to be *completely* useless with a
missing device, because none of your file data will be usably intact.
If you want the FS to behave well when you lose a device, you'll
need some kind of actual redundancy in the data storage part -- RAID-1
would be my recommendation (it stores two copies of each piece of
data, so you can lose up to one device and still be OK).
Hugo.
--
Hugo Mills | One of these days, I'll catch that man without a
hugo@... carfax.org.uk | quotation, and he'll look undressed.
http://carfax.org.uk/ |
PGP: E2AB1DE4 | Leto Atreides, Dune
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2017-07-25 13:47 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
2017-07-25 13:46 ` Hugo Mills [this message]
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=20170725134656.GL7140@carfax.org.uk \
--to=hugo@carfax.org.uk \
--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).