From: Hugo Mills <hugo@carfax.org.uk>
To: Philip Louis Moetteli <Philip.Moetteli@unige.ch>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: RAID system with adaption to changed number of disks
Date: Tue, 11 Oct 2016 16:06:01 +0000 [thread overview]
Message-ID: <20161011160601.GI7683@carfax.org.uk> (raw)
In-Reply-To: <D379E551-1272-4548-9601-0CE4C1A8C012@unige.ch>
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
On Tue, Oct 11, 2016 at 03:14:30PM +0000, Philip Louis Moetteli wrote:
> Hello,
>
>
> I have to build a RAID 6 with the following 3 requirements:
>
> • Use different kinds of disks with different sizes.
> • When a disk fails and there's enough space, the RAID should be able to reconstruct itself out of the degraded state. Meaning, if I have e. g. a RAID with 8 disks and 1 fails, I should be able to chose to transform this in a non-degraded (!) RAID with 7 disks.
> • Also the other way round: If I add a disk of what size ever, it should redistribute the data, so that it becomes a RAID with 9 disks.
>
> I don’t care, if I have to do it manually.
> I don’t care so much about speed either.
>
> Is BTrFS capable of doing that?
1) Take a look at http://carfax.org.uk/btrfs-usage/ which will tell
you how much space you can get out of a btrfs array with different
sized devices.
2) Btrfs's parity RAID implementation is not in good shape right
now. It has known data corruption issues, and should not be used in
production.
3) The redistribution of space is something that btrfs can do. It
needs to be triggered manually at the moment, but it definitely
works.
Hugo.
--
Hugo Mills | We are all lying in the gutter, but some of us are
hugo@... carfax.org.uk | looking at the stars.
http://carfax.org.uk/ |
PGP: E2AB1DE4 | Oscar Wilde
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2016-10-11 17:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 15:14 RAID system with adaption to changed number of disks Philip Louis Moetteli
2016-10-11 16:06 ` Hugo Mills [this message]
2016-10-11 23:58 ` Chris Murphy
2016-10-12 1:32 ` Qu Wenruo
2016-10-12 4:37 ` Zygo Blaxell
2016-10-12 5:48 ` Qu Wenruo
2016-10-12 17:19 ` Zygo Blaxell
2016-10-12 19:55 ` Adam Borowski
2016-10-12 21:10 ` Zygo Blaxell
2016-10-13 3:40 ` Adam Borowski
2016-10-12 20:41 ` Chris Murphy
2016-10-13 0:35 ` Qu Wenruo
2016-10-13 21:03 ` Zygo Blaxell
2016-10-14 1:24 ` Qu Wenruo
2016-10-14 7:16 ` Chris Murphy
2016-10-14 19:55 ` Zygo Blaxell
2016-10-14 21:19 ` Duncan
2016-10-14 21:38 ` Chris Murphy
2016-10-14 22:30 ` Chris Murphy
2016-10-15 3:19 ` Zygo Blaxell
2016-10-12 7:02 ` Anand Jain
2016-10-12 7:25 ` Roman Mamedov
2016-10-12 17:31 ` Zygo Blaxell
2016-10-12 19:19 ` Zygo Blaxell
2016-10-12 19:33 ` Roman Mamedov
2016-10-12 20:33 ` Zygo Blaxell
2016-10-11 16:37 ` Austin S. Hemmelgarn
2016-10-11 17:16 ` Tomasz Kusmierz
2016-10-11 17:29 ` ronnie sahlberg
2016-10-12 1:33 ` Dan Mons
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=20161011160601.GI7683@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=Philip.Moetteli@unige.ch \
--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.