From: Bill Davidsen <davidsen@tmr.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: LCID Fire <lcid-fire@gmx.net>, linux-raid@vger.kernel.org
Subject: Re: Recreate raid 10 array
Date: Wed, 08 Apr 2009 17:47:51 -0400 [thread overview]
Message-ID: <49DD1B87.2050804@tmr.com> (raw)
In-Reply-To: <87prfpdm8y.fsf@frosties.localdomain>
Goswin von Brederlow wrote:
> LCID Fire <lcid-fire@gmx.net> writes:
>
>
>> On my raid10 array (4 drives) I've had 2 drives (the same model) which
>> got disconnected by the kernel (almost at the same time). It seems
>> like both were one raid1 part so one half of the raid0 is missing.
>> Afterwards I tried to readd the drives again (my bad) so now I'm stuck
>> with 1 half of the raid0 part being present and valid and the other (2
>> drives) marked as spare.
>> The thing I'd like to do is:
>> - Take 2 new drives (different manufacturers)
>> - Clone one of the valid and one of the spare drives to the new drives
>> - Try to reassemble the array.
>> Problem is - is this even possible?
>> How do I tell mdadm to not care about the spare state?
>> Does the kernel write bogus data to the still valid drives if the
>> other 2 fail?
>>
>> Would be great if someone could enlighten me ;)
>>
>> P.S.: Does someone know how to easily report the different sata errors
>> which the kernel encounters?
>>
>
> mdadm --create --assume-clean -l 10 -n 4 /dev/mdX /dev/copied_disk_1 /dev/copied_disk2 missing missing
>
> You need to match the create parameters exactly with the ones you
> initially used (near/offset/farcopies? stripe size? ...) and the order
> of devices is relevant so you might have to shuffle the disk
> arguments. So just try different orders till the result can be mounted
> or fscked. With the wrong options the mount/fsck could screw up the
> data but then you copy the disk again for the next try. It should be
> reasonably obvious when mount/fsck goes wrong as it should find tons
> of errors. Mostly I would expect mount/fsck to just fail with the
> wrong mdadm args though.
>
May I say that this makes a great case for saving the contents of some
files to a safe place when the system is up and running right.? Maybe
all of /etc, and at least a "tree /sys" and /proc/mdstat would be
useful, preferably on something readable like a CD or USB flash drive,
so you have a chance of reading it if you can't boot.
Of course a rescue flash drive is pretty useful as well, so that's
probably the way to go.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
"You are disgraced professional losers. And by the way, give us our money back."
- Representative Earl Pomeroy, Democrat of North Dakota
on the A.I.G. executives who were paid bonuses after a federal bailout.
next prev parent reply other threads:[~2009-04-08 21:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 19:49 Recreate raid 10 array LCID Fire
2009-04-07 6:13 ` Goswin von Brederlow
2009-04-08 21:47 ` Bill Davidsen [this message]
2009-04-08 21:57 ` Andrew Burgess
2009-04-08 22:13 ` Goswin von Brederlow
2009-04-08 22:14 ` LCID Fire
2009-04-09 10:47 ` Andrew Burgess
2009-04-10 1:41 ` Goswin von Brederlow
2009-04-09 22:38 ` Bill Davidsen
2009-04-10 11:01 ` LCID Fire
2009-04-10 14:25 ` LCID Fire
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=49DD1B87.2050804@tmr.com \
--to=davidsen@tmr.com \
--cc=goswin-v-b@web.de \
--cc=lcid-fire@gmx.net \
--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.