From: Mark Davies <mark@curly.ii.net>
To: Neil Brown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: raid5 recovery dramas.
Date: Fri, 27 Jun 2008 19:14:51 +0800 [thread overview]
Message-ID: <4864CBAB.90201@curly.ii.net> (raw)
In-Reply-To: <18532.49368.984453.933541@notabene.brown>
Neil Brown wrote:
> You are in a rather stick situation.
Hmm, yes, I'm starting to realise that.
>
> Neither sdd1 or sde1 know where they belong in the array. If they
> did, then "mdadm --assemble --force" would probably be able to help
> you (I should test that). But they don't.
>
> Do you have any boot logs from before you started the reshape that
> show which device fills which slot in the array?
>
Not that I can find, and the physical drives have changed since I used
dd_rescue to recover from the bad sectors.
> sdd1 has an event count of 0. That is really odd. Any idea how that
> happened? Did you remove it from the array and try to add it back?
> That wouldn't have been a good idea.
>
I don't recall removing any drives, however it was a month or so ago
that this saga started. I was fairly careful to not do anything
irreversable I think.
Just checked the bash history, and I didn't remove any drives. Amusing
history though - you can almost smell the desperation and fear in every
entry.
> I'm at a bit of a loss as to what to suggest. The data is mostly
> there, but getting it back is tricky.
>
> What you need to do is
> choose one of sdd and sde which you think is device '3'
> (sdc is 0, sdb is 1, sda is 2).
> rewrite the metadata to assert this fact
> assemble the array read-only with sd[abc] and the one you choose
> read the data to make sure it is all where
> switch to read-write so the reshape competes, leaving you with
> a degraded array
> add the other drive and let it recover.
>
> The early steps in particular are not easy.
Since there's only two options, what's to stop me taking a backup of the
metadata, and then rewriting the metadata on one drive, mounting it,
seeing if it makes sense. If it does, great. If it doesn't, then
restore the metadata and repeat the process on the other drive.
Or am I missing an important step?
>
> I'll try to find some time to experiment, but I cannot promise
> anything.
>
> If you can remember everything you tried to do (maybe in
> .bash_history) that might help.
>
> NeilBrown
next prev parent reply other threads:[~2008-06-27 11:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 6:05 raid5 recovery dramas Mark Davies
2008-06-26 2:43 ` Mark Davies
2008-06-26 13:38 ` David Greaves
2008-06-26 14:25 ` Mark Davies
2008-06-27 10:28 ` Neil Brown
2008-06-27 11:14 ` Mark Davies [this message]
2008-06-27 20:44 ` Neil Brown
2008-06-30 7:03 ` Mark Davies
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=4864CBAB.90201@curly.ii.net \
--to=mark@curly.ii.net \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).