All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.