linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mathias Burén" <mathias.buren@gmail.com>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Growing 6 HDD RAID5 to 7 HDD RAID6
Date: Fri, 22 Apr 2011 10:39:07 +0100	[thread overview]
Message-ID: <BANLkTinAUbMdh=FE8s9Qp6QJyfgp_pvCpA@mail.gmail.com> (raw)
In-Reply-To: <4DA58CB0.3020109@anonymous.org.uk>

On 13 April 2011 12:44, John Robinson <john.robinson@anonymous.org.uk> wrote:
> (Subject line amended by me :-)
>
> On 12/04/2011 17:56, Mathias Burén wrote:
> [...]
>>
>> I'm approaching over 6.5TB of data, and with an array this large I'd
>> like to migrate to RAID6 for a bit more safety. I'm just checking if I
>> understand this correctly, this is how to do it:
>>
>> * Add a HDD to the array as a hot spare:
>> mdadm --manage /dev/md0 --add /dev/sdh1
>>
>> * Migrate the array to RAID6:
>> mdadm --grow /dev/md0 --raid-devices 7 --level 6
>
> You will need a --backup-file to do this, on another device. Since you are
> keeping the same number of data discs before and after the reshape, the
> backup file will be needed throughout the reshape, so the reshape will take
> perhaps twice as long as a grow or shrink. If your backup-file is on the
> same disc(s) as md0 is (e.g. on another partition or array made up of other
> partitions on the same disc(s)), it will take way longer (gazillions of
> seeks), so I'd recommend a separate drive or if you have one a small SSD for
> the backup file.
>
> Doing the above with --layout=preserve will save you doing the reshape so
> you won't need the backup file, but there will still be an initial sync of
> the Q parity, and the layout will be RAID4-alike with all the Q parity on
> one drive so it's possible its performance will be RAID4-alike too i.e.
> small writes never faster than the parity drive. Having said that, streamed
> writes can still potentially go as fast as your 5 data discs, as per your
> RAID5. In practice, I'd be surprised if it was faster than about twice the
> speed of a single drive (the same as your current RAID5), and as Neil Brown
> notes in his reply, RAID6 doesn't currently have the read-modify-write
> optimisation for small writes so small write performance is liable to be
> even poorer than your RAID5 in either layout.
>
> You will never lose any redundancy in either of the above, but you won't
> gain RAID6 double redundancy until the reshape (or Q-drive sync with
> --layout=preserve) has completed - just the same as if you were replacing a
> dead drive in an existing RAID6.
>
> Hope the above helps!
>
> Cheers,
>
> John.
>
>

Hi,

Thanks for the replies. Allright, here we go;

 $ mdadm --grow /dev/md0 --bitmap=none
 $ mdadm --manage /dev/md0 --add /dev/sde1
 $ mdadm --grow /dev/md0 --verbose --layout=preserve  --raid-devices 7
--level 6 --backup-file=/root/md-raid5-to-raid6-backupfile.bin
mdadm: level of /dev/md0 changed to raid6

$ cat /proc/mdstat

                                                             Fri Apr
22 10:37:44 2011

Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sde1[7] sdg1[0] sdh1[6] sdf1[5] sdc1[3] sdd1[4] sdb1[1]
      9751756800 blocks super 1.2 level 6, 64k chunk, algorithm 18
[7/6] [UUUUUU_]
      [>....................]  reshape =  0.0% (224768/1950351360)
finish=8358.5min speed=3888K/sec

unused devices: <none>

And in dmesg:


 --- level:6 rd:7 wd:6
 disk 0, o:1, dev:sdg1
 disk 1, o:1, dev:sdb1
 disk 2, o:1, dev:sdd1
 disk 3, o:1, dev:sdc1
 disk 4, o:1, dev:sdf1
 disk 5, o:1, dev:sdh1
RAID conf printout:
 --- level:6 rd:7 wd:6
 disk 0, o:1, dev:sdg1
 disk 1, o:1, dev:sdb1
 disk 2, o:1, dev:sdd1
 disk 3, o:1, dev:sdc1
 disk 4, o:1, dev:sdf1
 disk 5, o:1, dev:sdh1
 disk 6, o:1, dev:sde1
md: reshape of RAID array md0
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than
200000 KB/sec) for reshape.
md: using 128k window, over a total of 1950351360 blocks.

IIRC there's a way to speed up the migration, by using a larger cache
value somewhere, no?

Thanks,
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-22  9:39 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
2011-04-13 11:44 ` Growing 6 HDD RAID5 to 7 HDD RAID6 John Robinson
2011-04-22  9:39   ` Mathias Burén [this message]
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='BANLkTinAUbMdh=FE8s9Qp6QJyfgp_pvCpA@mail.gmail.com' \
    --to=mathias.buren@gmail.com \
    --cc=john.robinson@anonymous.org.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 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).