From: "Cat'Killer" <catkiller@gmail.com>
To: linux-raid@vger.kernel.org
Subject: RAID 5 build time optimization question and experiments.
Date: Fri, 11 Dec 2009 14:55:31 +0000 [thread overview]
Message-ID: <ad15b8920912110655k62c8b6ber8b366731cf1e85f3@mail.gmail.com> (raw)
Hi All,
I am currently needing to build a RAID 5 on ten large 1TB Disks in
several different systems, that will come over time.
The systems are all running exactly the same linux version and mdadm
tools, as well as being exactly the same hardware, and are populated
with exactly the same drives (same capacity, manufacturer model and
batch).
Creating a RAID 5 array on each of these devices will take approx
15Hours+, which led me to think of the following procedure/experiment
to create them faster.
I found a way using Doug Gilbert's great sg3utils to zero all these
disks in a very efficient manner, using sgp_dd, at near drive
bandwidth, and proceeded to zero all the disks fully in about 4 hours!
Once done, I then created a RAID 5 on 10 disks, waited for the rebuild
to complete, stopped the array using mdadm, and dumped each of the
RAID's components superblocks to files.
The command used for the RAID 5 creation was the following:
mdadm --create -vvv --force --run --metadata=1.2 /dev/md/d0 --level=5
--size=35879936 --chunk=64 --name=0125465 -n10 --bitmap=internal
--bitmap-chunk=4096 --layout=ls /dev/sde2 /dev/sdj2 /dev/sdf2
/dev/sdg2 /dev/sdb2 /dev/sdc2 /dev/sdh2 /dev/sdi2 /dev/sdd2 /dev/sda2
The create worked fine and I waited for the rebuild to be complete
before stopping the array and dumping the SBs.
I then proceeded to write these same superblocks to 10 new similar
disks in a different system, and used the following command to
assemble the array:
bin/mdadm/mdadm --assemble -vvv --force /dev/md/d0 --run
--name=0125465 /dev/sde2 /dev/sdj2 /dev/sdf2 /dev/sdg2 /dev/sdb2
/dev/sdc2 /dev/sdh2 /dev/sdi2 /dev/sdd2 /dev/sda2
This subsequently led to my new array to be instantly online with no
rebuild required.
I figured this whole procedure would work since the disks are
completely zeroed, the parity information should be zero anyways on
the drives. Since zeroing all these drives took me 4 hours, I would
save nearly 10 hours for any
subsequent array I would need to build in the future, just by zeroing
their components and dd-ing the SBs onto them.
Do you think this method has its flaws? Do you think the data on it
should be safe? How about the bitmap, would that be safe as long as
the superblock has been copied, or should I copy this over too?
Thanks in advance.
Ben.
next reply other threads:[~2009-12-11 14:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-11 14:55 Cat'Killer [this message]
2009-12-11 15:29 ` RAID 5 build time optimization question and experiments Robin Hill
2009-12-11 15:44 ` Joe Landman
[not found] <4B227932.80503@mpstor.com>
2009-12-11 16:57 ` Cat'Killer
2009-12-11 22:35 ` 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=ad15b8920912110655k62c8b6ber8b366731cf1e85f3@mail.gmail.com \
--to=catkiller@gmail.com \
--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).