All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Waterman <davidmaxwaterman@fastmail.co.uk>
To: linux-raid@vger.kernel.org
Subject: Re: RAID5 -> RAID6
Date: Sat, 28 Mar 2009 22:54:56 +0200	[thread overview]
Message-ID: <49CE8EA0.9080704@fastmail.co.uk> (raw)
In-Reply-To: <a741976bf24fa274ac54be1f31d8bc2e.squirrel@neil.brown.name>

NeilBrown wrote:
> Wait 3 months :-)
>   

Sounds good. I'm in no particular hurry. Increasing capacity would be 
nice, but I'm not sure I want to do that since I only have a 1TB drive 
for backup...as such, the slow version of 1a/ sounds reasonable - I have 
a spare 80GB drive in the same machine that I could make use of to make 
it not-so-dangerous.

I guess I might consider a grow too - perhaps I'll have another drive by 
then so my backup can be bigger.

Thanks for the advice...I'll keep an eye out for the new support.

Max.

> 2.6.30 should contains support for this sort of conversion.  It is
> already written (mostly) but still needs some testing.
>
>
> Your options would then include:
>  1/  convert that raid5 to a raid6 of the same size but with one
>      extra device.  This device would store all the 'Q' blocks so
>      it could become a write bottle neck
>  1a/ as above, but then restripe the array so that the Q block is
>      rotated among the drives.  This process is either dangerous - in
>      that a crash would kill your data, or slow - in that all the data
>      would need to be copied elsewhere in chunks while the corresponding
>      chunk of the array was restriped.
>  2/  convert to raid6 and grow at the same time.  i.e. add both spares
>      using one of them to support the conversion to raid6 and the
>      other to increase the space.  You could then arrange to restripe
>      an grow at the same time which is faster/safer than striping in-place.
>  3/  Possibly you could restripe-and-grow, then restripe-and-shrink
>      so you end up with a 7 device RAID6 with properly rotating parity,
>      but don't go through the slow/dangerous restripe-in-place.
>      I'll need to do some experiments to see if that would actually
>      be faster

  reply	other threads:[~2009-03-28 20:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-28 13:05 RAID5 -> RAID6 Max Waterman
2009-03-28 20:41 ` NeilBrown
2009-03-28 20:54   ` Max Waterman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-03-08  3:20 Leslie Rhorer
2010-03-08  3:27 ` RAID5 - RAID6 Leslie Rhorer
2010-03-08  4:19   ` Michael Evans
2010-03-08  3:31 Michael Evans
2010-03-08  8:59 ` RAID5 - RAID6 Leslie Rhorer
2010-03-08  9:09   ` Michael Evans

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=49CE8EA0.9080704@fastmail.co.uk \
    --to=davidmaxwaterman@fastmail.co.uk \
    --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 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.