linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: DeadManMoving <sequel@neofreak.org>
To: Phil Turmel <philip@turmel.org>
Cc: linux-raid@vger.kernel.org, DeadManMoving <sequel@neofreak.org>
Subject: Re: failed RAID 5 array
Date: Fri, 14 Nov 2014 10:53:34 -0500	[thread overview]
Message-ID: <1415980414.4241.49.camel@lappy.neofreak.org> (raw)
In-Reply-To: <5466173F.2060007@turmel.org>

Hi Phil,

On Fri, 2014-11-14 at 09:52 -0500, Phil Turmel wrote:
> Hi Tony,
> 
> {Convention on kernel.org is to trim posts & bottom or interleave posts}
> 

Thanks a lot for the advice.

> 
> Indeed.
> 
> At this point, I would use --create --assume-clean, along with
> "missing".  You have a recent enough mdadm to specify
> --data-offset=2048, which you definitely need.  Something like:
> 
> mdadm --create /dev/mdX --assume-clean --data-offset=2048 \
> 	--level=5 --raid-devices=4 --chunk=512 \
> 	missing /dev/sd{f,i,h}
> 
> You should verify the Device Role numbers with mdadm -E again, as your
> drive letters have changed from the initial report.  To be absolutely
> sure, I suggest you record drive serial numbers for each role #.  Also
> note the use of braces instead of square brackets--bash re-orders the
> latter, and that would break your array.  For this type of recovery, it
> is vital that the devices be listed precisely in device role order,
> starting with zero.
> 
> After creation, verify that the space before and space after stats for
> each device match the original report, before fsck or mount.
> (--data-offset controls space before, that plus --size controls space
> after.)


That is my plan to closely look at devices role to ensure proper order
in array creation. To avoid any mistake, i was planning to
use /dev/sda /dev/sdb /dev/sdc syntax instead of /dev/sd{a,b,c}, it's
probably the same, is it not?

Like said in my original post, i am making duplicate copies of each
disk, just to be extra safe. I already did it for two disks i have on
hands. I have ordered and waiting for two other drives to come in. As
soon as the copies will be done for the two other disks, i will try that
procedure. I will use the --data-offset parameter as you suggest.


Thank you so much for your help!

Tony



  reply	other threads:[~2014-11-14 15:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12 15:58 failed RAID 5 array DeadManMoving
2014-11-13 22:56 ` Phil Turmel
2014-11-14 13:19   ` DeadManMoving
2014-11-14 13:42     ` Phil Turmel
2014-11-14 14:08       ` DeadManMoving
2014-11-14 14:52         ` Phil Turmel
2014-11-14 15:53           ` DeadManMoving [this message]
2014-11-14 16:04             ` Phil Turmel
2014-11-15  6:42               ` Wolfgang Denk
2014-11-15 15:03                 ` Phil Turmel
  -- strict thread matches above, loose matches on Subject: below --
2004-09-10 12:31 failed raid " Jim Buttafuoco
2004-09-10 13:03 ` Jim Buttafuoco

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=1415980414.4241.49.camel@lappy.neofreak.org \
    --to=sequel@neofreak.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=philip@turmel.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).