linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ryan B. Lynch" <rlynch@strozllc.com>
To: maarten van den Berg <maarten@vbvb.nl>
Cc: linux-raid@vger.kernel.org
Subject: Re: two-disk-failure question
Date: Wed, 22 Oct 2003 12:55:12 -0400	[thread overview]
Message-ID: <3F96B670.2020802@strozllc.com> (raw)
In-Reply-To: <200310172315.56815.maarten@vbvb.nl>

Hey Maarten,

Maarten van den Berg wrote:

>cables and such. So my obvious question is:  Is this step (mkraid --force 
>with one of the offline disks defined as failed-disk) destructive, or could I 
>(theoretically) experiment endlessly with the order in which the disks are 
>defined in /etc/raidtab before I decide to mount it read-write and raidhotadd 
>a fresh disk ?
>
I had to do this about a year ago, on account of a bad IDE controller, 
and was successful on the first try.  I recall from the HOWTO that the 
'mkraid --force' command IS destructive, and it WILL lose the array if 
you get it wrong.

My incident involved data which would have been a bear to restore from 
backup, so I didn't take any chances.  Prior to the 'mkraid --force' 
step, I labelled each physical disk with it's number in the array, and 
then copied each disk to an identical disk using the 'dd' command 
[somthing like 'dd if=/dev/sda of=/dev/sdb bs=8192' where /dev/sda is 
the original and /dev/sdb is a handy blank disk, repeated for each 
original disk in the array].  Of course, this required five extra hard 
disks, but I had them lying around anyway.  And that's the foolproof 
method.  If you're really paranoid (you don't have a backup of the 
failed array), you might want to also do an 'md5sum /dev/sdb; md5sum 
/dev/sda' and compare the two hash values to ensure that each copy is 
faithful--re-do the copy that doesn't pass the hash check.  Since you're 
juggling so many hard drives, make sure you label all the 
disks--scotch-taped sticky notes on the cover, with the array #s written 
in felt pen worked for me.

Then, you can run off and do whatever with the originals, and you'll 
always have something to go back to if you utterly wipe out your array 
while trying to restore it.  If that happens, you just take the 
clobbered disks, and re-do the 'dd' command to write the copy back to 
the originals.  Hash if necessary, and go to town again.  Repeat until 
you either successfully restore the array, or you swear off computers 
and enroll in florists' school.

Keep in mind that this can add a LOT of time to a restore operation.  
With Western Digital WD200 IDE disks (7200 RPM, 18.6 GB), I can move 
about 30-22 MB/sec (beginning-end) on direct disk-to-disk copies like 
this, with an average around 25 MB/sec.  That's ~1.5 GB/min, so you can 
estimate your own ETAs.  Hashing will take a similar amount of time if 
you use 'md5sum' on a reasonably fast machine (P4 1.8+).

-R


      reply	other threads:[~2003-10-22 16:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-17 21:15 two-disk-failure question maarten van den Berg
2003-10-22 16:55 ` Ryan B. Lynch [this message]

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=3F96B670.2020802@strozllc.com \
    --to=rlynch@strozllc.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=maarten@vbvb.nl \
    /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).