linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mathias Burén" <mathias.buren@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: Roman Mamedov <rm@romanrm.ru>, Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Growing 6 HDD RAID5 to 7 HDD RAID5
Date: Tue, 12 Apr 2011 22:53:44 +0100	[thread overview]
Message-ID: <BANLkTimsU88r2yGpRL+4xB1hMU9-SGHvvA@mail.gmail.com> (raw)
In-Reply-To: <20110413071554.6537c52c@notabene.brown>

On 12 April 2011 22:15, NeilBrown <neilb@suse.de> wrote:
> On Wed, 13 Apr 2011 00:22:38 +0600 Roman Mamedov <rm@romanrm.ru> wrote:
>
>> On Tue, 12 Apr 2011 18:21:13 +0100
>> Mathias Burén <mathias.buren@gmail.com> wrote:
>>
>> > If I use --layout=preserve , what impact will that have?
>> > If I preserve the layout, what is the final result of the array
>> > compared to not preserving it?
>>
>> Neil wrote about this on his blog:
>> "It is a very similar process that can now be used to convert a RAID5 to a
>> RAID6. We first change the RAID5 to RAID6 with a non-standard layout that has
>> the parity blocks distributed as normal, but the Q blocks all on the last
>> device (a new device). So this is RAID6 using the RAID6 driver, but with a
>> non-RAID6 layout. So we "simply" change the layout and the job is done."
>> http://neil.brown.name/blog/20090817000931
>>
>> Admittedly it is not completely clear to me what are the long-term downsides of
>> this layout. As I understand it does fully provide the RAID6-level redundancy.
>> Perhaps just the performance will suffer a bit? Maybe someone can explain this
>> more.
>
> If you specify --layout=preserve, then all the 'Q' blocks will be on one disk.
> As every write needs to update a Q block, every write will write to that disk.
>
> With our current RAID6 implementation that probably isn't a big cost - for
> any write, we need to either read from or write to each disk anyway.
>
> Anyway:  the only possible problem would be a performance problem, and I
> really don't know what performance impact there is - if any.
>
>>
>> If anything, I think it is safe to use this layout for a while, e.g. in case
>> you don't want to rebuild 'right now'. You can always change the layout to the
>> traditional one later, by issuing "--grow --layout=normalise". Or perhaps if
>> you plan to add another disk soon, you can normalise it on that occasion, and
>> still gain the benefit of only one full reshape.
>
> Note that doing a normalise by itself later will be much slower than not
> doing a preserve now.
> Doing the normalise later when growing the the device again would be just as
> fast as no doing the preserve now.
>
> NeilBrown
>
>
>>
>> >  Will the array have redundancy during the rebuild of the new drive?
>>
>> If you choose --layout=preserve, your array immediately becomes a RAID6 with
>> one rebuilding drive. So this is the kind of redundancy you will have during
>> that rebuild - tolerance of up to one more (among the "old" drives) failure,
>> in other words, identical to what you currently have with RAID5.
>>
>
>

Right, so using --preserve seems like a sane and good option. Thanks
for the info, I'll let you know what happens, HDD should arrive the
next few days.

// Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-04-12 21:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-12 16:56 Growing 6 HDD RAID5 to 7 HDD RAID5 Mathias Burén
2011-04-12 17:14 ` Roman Mamedov
2011-04-12 17:21   ` Mathias Burén
2011-04-12 18:22     ` Roman Mamedov
2011-04-12 21:15       ` NeilBrown
2011-04-12 21:53         ` Mathias Burén [this message]
2011-04-13 11:44 ` Growing 6 HDD RAID5 to 7 HDD RAID6 John Robinson
2011-04-22  9:39   ` Mathias Burén
2011-04-22 10:05     ` Mathias Burén
2011-04-29 22:45       ` Mathias Burén

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=BANLkTimsU88r2yGpRL+4xB1hMU9-SGHvvA@mail.gmail.com \
    --to=mathias.buren@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=rm@romanrm.ru \
    /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).