From: Ming Zhang <mingz@ele.uri.edu>
To: dean gaudet <dean@arctic.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: proactive raid5 disk replacement success (using bitmap + raid1)
Date: Thu, 22 Jun 2006 19:50:25 -0400 [thread overview]
Message-ID: <1151020225.2686.92.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0604231823560.22072@twinlark.arctic.org>
Hi Dean
Thanks a lot for sharing this.
I am not quite understand about these 2 commands. Why we want to add a
pre-failing disk back to md4?
mdadm --zero-superblock /dev/sde1
mdadm /dev/md4 -a /dev/sde1
Ming
On Sun, 2006-04-23 at 18:40 -0700, dean gaudet wrote:
> i had a disk in a raid5 which i wanted to clone onto the hot spare...
> without going offline and without long periods without redundancy. a few
> folks have discussed using bitmaps and temporary (superblockless) raid1
> mappings to do this... i'm not sure anyone has tried / reported success
> though. this is my success report.
>
> setup info:
>
> - kernel version 2.6.16.9 (as packaged by debian)
> - mdadm version 2.4.1
> - /dev/md4 is the raid5
> - /dev/sde1 is the disk in md4 i want to clone from
> - /dev/sdh1 is the hot spare from md4, and is the clone target
> - /dev/md5 is an unused md device name
>
> here are the exact commands i issued:
>
> mdadm -Gb internal --bitmap-chunk=1024 /dev/md4
> mdadm /dev/md4 -r /dev/sdh1
> mdadm /dev/md4 -f /dev/sde1 -r /dev/sde1
> mdadm --build /dev/md5 -ayes --level=1 --raid-devices=2 /dev/sde1 missing
> mdadm /dev/md4 --re-add /dev/md5
> mdadm /dev/md5 -a /dev/sdh1
>
> ... wait a few hours for md5 resync...
>
> mdadm /dev/md4 -f /dev/md5 -r /dev/md5
> mdadm --stop /dev/md5
> mdadm /dev/md4 --re-add /dev/sdh1
> mdadm --zero-superblock /dev/sde1
> mdadm /dev/md4 -a /dev/sde1
>
> this sort of thing shouldn't be hard to script :)
>
> the only times i was without full redundancy was briefly between the "-r"
> and "--re-add" commands... and with bitmap support the raid5 resync for
> each of those --re-adds was essentially zero.
>
> thanks Neil (and others)!
>
> -dean
>
> p.s. it's absolutely necessary to use "--build" for the temporary raid1
> ... if you use --create mdadm will rightfully tell you it's already a raid
> component and if you --force it then you'll trash the raid5 superblock and
> it won't fit into the raid5 any more...
> -
> 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
next prev parent reply other threads:[~2006-06-22 23:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-24 1:40 proactive raid5 disk replacement success (using bitmap + raid1) dean gaudet
2006-06-22 23:50 ` Ming Zhang [this message]
2006-06-23 0:09 ` dean gaudet
2006-06-23 0:13 ` Ming Zhang
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=1151020225.2686.92.camel@localhost.localdomain \
--to=mingz@ele.uri.edu \
--cc=dean@arctic.org \
--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