linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Turmel <philip@turmel.org>
To: Benjamin ESTRABAUD <be@mpstor.com>
Cc: Ivan Yordanov <iyordanov@taxback.com>,
	Nikolay Kichukov <nkichukov@taxback.com>,
	linux-raid@vger.kernel.org
Subject: Re: [Fwd: Re: Missing superblock on one of the raid devices on raid 0 with 1.2 metadata]
Date: Fri, 15 Mar 2013 12:52:50 -0400	[thread overview]
Message-ID: <514351E2.5030408@turmel.org> (raw)
In-Reply-To: <51434C5B.9080007@mpstor.com>

Hi Ivan,

On 03/15/2013 12:29 PM, Benjamin ESTRABAUD wrote:

[trim /]

> The fact that you have the position of all the other drives from the
> array is good. Now we want the last drive's superblock to be written.
> Since we know the position of all the drives, and assuming you know the
> *exact* arguments passed to mdadm when you first created your raid0
> (correct metadata version, chunk size, etc. (most can be found in the
> existing superblocks), you could call "mdadm --create " with the same
> version of mdadm and MD used when creating the array initially, the same
> options and arguments, and *very important* the drives in the same
> order, which I believe to be: /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
> (according to the info above).
> 
> This will create a new array, but since you are recreating the same
> *exact* array, the existing data should be there and available untouched.

This is all correct, and is the correct next step.

> However, as a word of warning, many things can go wrong this this
> command: If you were to recreate the array slightly differently and
> start overwriting your array you would destroy the data on it. The fact
> that it is a RAID0 is good since creating a new array won't start a
> resync that could be fatal should you have made a mistake providing the
> arguments for the recreation. So the above should be generally safe,
> provided you keep a copy of the information you gave us above and match
> the "create" arguments perfectly.

You can check your work by re-issuing the "mdadm -E" commands after
re-creating the array.  The data offset and chunk size must match the
originals.

If they do, then you can mount the filesystem.

Phil

  reply	other threads:[~2013-03-15 16:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1363335578.29317.0.camel@hanna64.taxback.ess.ie>
2013-03-15  8:24 ` [Fwd: Re: Missing superblock on one of the raid devices on raid 0 with 1.2 metadata] Ivan Yordanov
2013-03-15 16:29   ` Benjamin ESTRABAUD
2013-03-15 16:52     ` Phil Turmel [this message]
2013-03-15 16:57       ` Benjamin ESTRABAUD

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=514351E2.5030408@turmel.org \
    --to=philip@turmel.org \
    --cc=be@mpstor.com \
    --cc=iyordanov@taxback.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=nkichukov@taxback.com \
    /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).