linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: Guillaume ALLEE <guillaume.allee@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: 2nd Faulty drive while rebuilding array on RAID5
Date: Thu, 29 Oct 2015 08:21:58 -0400	[thread overview]
Message-ID: <56320F66.6030109@turmel.org> (raw)
In-Reply-To: <CABEdK7wDU42phn2RTqUQWVTCet5v+WqtRYoD0ezvHXpGioapmQ@mail.gmail.com>

Good morning Guillaume,

On 10/28/2015 04:35 PM, Guillaume ALLEE wrote:

> Thanks for your answer. I have tested my sda3 with badblocks and it
> seems really bad like 6 digits unreadable blocks...

Hmm.  Is there any chance your cabling or power supply is at fault?

>> Something's missing.  I see only sd[abcd]3.  Where's the report for
>> /dev/sde* ?
> Yep because /dev/sde is not part of my /dec/md1 array.

Ok.

> "ARRAY /dev/md1 level=raid5 num-devices=4 metadata=00.90
> UUID=426d71a2:5b25a168:a4e2eff2:d305f1c1
>    devices=/dev/sda3,/dev/sdb3,/dev/sdc3,/dev/sdd3"

Just for future reference:  you aren't expected to keep the output of
"mdadm -Es" as your permanent mdadm.conf.  Your system will be much more
robust if you trim that to just the MD device name and the UUID.

>> Yes, you have WD20EARS and ST3000DM001 drive models.  These are not safe
>> to use in raid arrays due to lack of error recovery control.
> Okay I will look at that for my next HDs.

Yes, it should guide your future purchasing, but you have a crisis on
your hands -- you *must* set your driver timeouts to deal with your
consumer-grade desktop drives or your array *will* crash again *soon*.

>> You need to stop the array and perform an '--assemble --force' with the
>> last four devices (exclude /dev/sdc).  The ones that have "Raid Device"
>> 0, 1, 2, & 3.
> Here is the assemble output.
> 
> #mdadm --assemble --force /dev/md1 /dev/sda3 /dev/sdb3 /dev/sdd3
> mdadm: no recogniseable superblock on /dev/sda3
> mdadm: /dev/sda3 has no superblock - assembly aborted

Hmmm.  You need three readable drives with original data to get out of
this trap.  What happened to the original /dev/sdc?  Using it with a
carefully constructed --create --assume-clean may be your only chance to
recover anything.

Also, before you risk wiping anything else, generate mdadm -E reports
for each device along with a "smartctl -i -A -l scterc" report.  That
ties the array details (especially role) for each device to the drive
serial number.  As you plug and unplug devices, names can change.

Just post that information inline in your next reply -- no need to use
pastebin.

Phil


      reply	other threads:[~2015-10-29 12:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-24 22:27 2nd Faulty drive while rebuilding array on RAID5 Guillaume ALLEE
2015-10-25 23:38 ` Phil Turmel
2015-10-28 20:35   ` Guillaume ALLEE
2015-10-29 12:21     ` Phil Turmel [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=56320F66.6030109@turmel.org \
    --to=philip@turmel.org \
    --cc=guillaume.allee@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 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).