From: Phil Turmel <philip@turmel.org>
To: Chris Finley <debenbain@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Wiki-recovering failed raid, overlay problem
Date: Sun, 02 Jun 2013 00:25:30 -0400 [thread overview]
Message-ID: <51AAC93A.40004@turmel.org> (raw)
In-Reply-To: <51AAA0B9.3050908@turmel.org>
Whoops, noticed that I dropped the list... Convention on kernel.org is
reply-to-all, as non-subscribers are welcome.
On 06/01/2013 09:32 PM, Phil Turmel wrote:
> On 06/01/2013 08:40 PM, Chris Finley wrote:
>> On Sat, Jun 1, 2013 at 4:30 PM, Phil Turmel <philip@turmel.org> wrote:
>>> Hi Chris,
>>>
>>> On 06/01/2013 02:23 AM, Chris Finley wrote:
>>>> I am trying to recover a failed Raid 5 array by following the guide at
>>>> https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID
>>>
>>> Stop. Report the *critical* details of your setup. At least:
>>
>> Thank you for the reply.
>>
>> Oh, yes. I'm the guy from an earlier post:
>> http://marc.info/?l=linux-raid&m=136840333618808&w=2
>
> I missed it--I must have been busy.
>
>> Because each of the drives had some read errors, I thought it would be
>> safer to make the first attempt with overlays. There is always the
>> possibility of me entering command incorrectly too :)
>
> As long as the original metadata is still present, mdadm is quite
> robust. Overlays are useful when you don't know the original metadata
> properties and don't have enough spare drives.
>
> The material provided is quite complete, but lacks a correlation between
> device names and drive serial numbers. I'd like some more confidence there:
>
> Please show the output of my 'lsdrv' script [1] as your system is now
> set up.
>
> Your drive with S/N S2H7JD2B105688 seems to be the worst, with
> triple-digit pending sectors. This suggests a mismatch between your
> drives' error correction time limits and the linux drivers' default
> timeout. And a lack of regular scrubbing to clean up pending sectors.
> "smartctl -l scterc" for each drive would give useful information.
> Anyways, the drive may not be really failing--it has zero relocations.
>
> If S2H7JD2B105688 was the old /dev/sdd, then it doesn't matter, but
> you've now lost the opportunity to correct those sectors.
>
> Phil
>
> [1] http://github.com/pturmel/lsdrv/
>
next prev parent reply other threads:[~2013-06-02 4:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 6:23 Wiki-recovering failed raid, overlay problem Chris Finley
2013-06-01 23:30 ` Phil Turmel
2013-06-02 0:40 ` Chris Finley
2013-06-02 1:32 ` Phil Turmel
2013-06-02 4:25 ` Phil Turmel [this message]
2013-06-02 5:07 ` Chris Finley
2013-06-02 13:53 ` Phil Turmel
2013-06-03 23:35 ` Chris Finley
2013-06-04 0:00 ` Phil Turmel
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=51AAC93A.40004@turmel.org \
--to=philip@turmel.org \
--cc=debenbain@gmail.com \
--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.