Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: linux-raid@vger.kernel.org
Subject: Why do I need 4 disks for a raid6?
Date: Tue, 17 Mar 2009 20:12:38 +0100	[thread overview]
Message-ID: <87ljr4hsk9.fsf@frosties.localdomain> (raw)

Hi,

I'm wondering why the kernel requires a raid6 to have at least 4
disks (of which at most 2 can be missing). Why not 3 disks?

I know a 1+2 disk raid6 sounds stupid but it has an use case. Let me
demonstrate this with raid5:

Lets say you started with a raid1 when you bought your computer:
mdadm --create -l 1 -n 2 /dev/md9 /dev/sda1 /dev/sdb1
a fewyears of use on /dev/md9 

Now you run out of space and went and bought a 3rd harddisk. What to
do now?
mdadm --stop /dev/md9
mdadm --create -l 5 -n 2 --assume-clean /dev/sda1 /dev/sdb1
mdadm --add /dev/md9 /dev/sdc1
mdadm --grow -n 3 /dev/md9

Voila. A nice raid5 with twice the size of the raid1. And no single
point of failure like degrading the raid1 and copying the data to a
degraded raid5 would have. And the downtime is just a minute to create
the new superblock.



Now for the raid6 case. With only 1 data disk and 2 parity disks all 3
disks should end up with identical data on them. In effect this should
be a 3 disk raid1, a cpu intensive one. Take an existing raid1 with 2
or 3 disks, stop the raid, create a new raid6 ovver it with
--assume-clean, start the raid. After that one can add more disks and
--grow -n 4/5/6/.. the raid6 to a sensible size. Again without going
into degraded mode.


So back to my original question: Why does the kernel require 4 disks
for a raid6 instead of allowing 3?

MfG
        Goswin

PS: Please CC me on replies.

             reply	other threads:[~2009-03-17 19:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17 19:12 Goswin von Brederlow [this message]
2009-03-18  3:41 ` Why do I need 4 disks for a raid6? david.geib
2009-03-18  9:50   ` Goswin von Brederlow
2009-03-18 18:12     ` david.geib
2009-03-18 12:18 ` Andre Noll
     [not found]   ` <49C0EA5F.9070901@vshift.com>
2009-03-18 12:35     ` Andre Noll
2009-03-18 14:08       ` Goswin von Brederlow
2009-03-18 14:26         ` Robin Hill
2009-03-18 18:48           ` Goswin von Brederlow
2009-04-01 16:08   ` H. Peter Anvin
2009-04-01 17:47     ` Andre Noll
2009-04-01 20:36       ` H. Peter Anvin
2009-04-01 18:07     ` Goswin von Brederlow
2009-04-01 19:05       ` H. Peter Anvin
2009-03-19 23:35 ` Neil Brown
2009-03-20 10:20   ` Goswin von Brederlow
2009-03-23 20:20   ` Nifty Fedora Mitch
2009-03-24 19:32     ` Goswin von Brederlow
2009-04-01 16:09       ` H. Peter Anvin

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=87ljr4hsk9.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=linux-raid@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