From: Ravi Pinjala <ravi@p-static.net>
To: Bart Noordervliet <bart@noordervliet.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Raid1 with 3 drives
Date: Fri, 05 Mar 2010 19:02:35 -0600 [thread overview]
Message-ID: <4B91A9AB.1020005@p-static.net> (raw)
In-Reply-To: <b7130efa1003051349p63733275g6b98fab32d6f497c@mail.gmail.com>
On 03/05/10 15:49, Bart Noordervliet wrote:
> On Fri, Mar 5, 2010 at 21:31, Josef Bacik<josef@redhat.com> wrote:
>>> Since I have three devices in a RAID1 pool, can it survive 2 drive failures?
>>
>> Yes, tho you won't be able to remove more than 1 at a time (since it wants you
>> to keep at least two disks around). Thanks,
>>
>> Josef
>
> Hmm, I would expect the raid1 data mode to keep 2 copies of each file
> and thus yield 50% effective storage capacity, even with 3 disks. I
> see no real reason to stick with the full-disk mirroring mentality of
> previous raid systems since raid implemented in a filesystem works
> differently. Or would it be difficult to implement btrfs raid1 like
> this?
>
> Maybe it's worth to consider leaving the burdened raid* terminology
> behind and name the btrfs redundancy modes more clearly by what they
> do. For instance "-d double|triple" or "-d 2n|3n". And for raid5/6 "-d
> single-parity|double-parity" or "-d n+1|n+2".
>
> Regards,
>
> Bart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
This would be pretty excellent - there's a real need for a storage
system where you can just give it a bunch of disks and a policy, and let
the system worry about the details. Current RAID implementations are
pretty inflexible, for example when dealing with disks of varying size.
--Ravi
prev parent reply other threads:[~2010-03-06 1:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-05 19:28 Raid1 with 3 drives Grady Neely
2010-03-05 19:40 ` Josef Bacik
2010-03-05 19:58 ` Chris Ball
2010-03-05 20:29 ` Grady Neely
2010-03-05 20:31 ` Josef Bacik
2010-03-05 21:49 ` Bart Noordervliet
2010-03-05 22:13 ` Mike Fedyk
2010-03-05 22:27 ` Hubert Kario
2010-03-06 1:02 ` Ravi Pinjala [this message]
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=4B91A9AB.1020005@p-static.net \
--to=ravi@p-static.net \
--cc=bart@noordervliet.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.