From: NeilBrown <neilb@suse.de>
To: Aaron Scheiner <blue@aquarat.za.net>
Cc: Stan Hoeppner <stan@hardwarefreak.com>, linux-raid@vger.kernel.org
Subject: Re: Grub-install, superblock corrupted/erased and other animals
Date: Fri, 5 Aug 2011 22:16:25 +1000 [thread overview]
Message-ID: <20110805221625.762f8415@notabene.brown> (raw)
In-Reply-To: <CADz4AWGrsP8tJ7U_YPa8Bs7rxUcW40-wTEtRmSykaBpQ0=V9ug@mail.gmail.com>
On Fri, 5 Aug 2011 13:28:41 +0200 Aaron Scheiner <blue@aquarat.za.net> wrote:
> "Wish I could have helped you recover the array. When a patient comes
> through emergency with 3 GSWs to the forehead and no pulse, there's
> nothing that can be done. :("
>
> Quite an analogy :P . Is it really that hopeless ? And of interest
> have you been in that situation ? I have the order of the array... so
> it should just be a case of reconstructing it in the same way it was
> created. Only one device was partitioned (as can be seen from the
> dmesg logs) and that device is known.
>
> Most of the array was backed up to another array, but there are some
> photos I'd like to recover. The array doesn't need to be functional
> any time soon (I'm happy to keep working on it for another 3 months if
> necessary).
>
> Besides, it's a good learning experience.
>
> I "re-created" the array using the drive order I specified in the
> previous e-mail, but replacing drive 9 with "missing". I then ran
> xfs_check on the md device and it failed (as it did with every other
> re-create attempt). I'll give your suggestion of xfs_repair -n a go :)
When you create the array, what 'data offset' does mdadm choose?
If not the same as the original the filesystem will of course not look right.
You might need to hack mdadm (super1.c) to set a different data_offset
NeilBrown
> .
>
> I'll have a look at the start of the md device with a hex editor and
> see if there's anything interesting there.
>
> On Fri, Aug 5, 2011 at 12:32 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
> > On 8/5/2011 5:04 AM, Aaron Scheiner wrote:
> >> I followed your advice and ran a scalpel instance for every drive in
> >> the array. The scanning process finished this morning yay (and
> >> obviously went a lot faster).
> >
> > Glad I could help.
> >
> > ...
> >> So now the next step would have been to re-create the array and check
> >
> > Unless Neil has some hex editor (or other similar) trick up his sleeve
> > that would allow you to manually recreate the sectors you hosed
> > installing grub..
> >
> >> if a file system check finds something... but because of the offsets
> >> that probably won't work ?
> >
> > If you are able to use the Force to assemble the disks in the correct
> > order, getting the raid device back up and running, then run 'xfs_repair
> > -n /dev/md0' to do the check. The '-n' means "no modify". xfs_repair
> > is better than xfs_check in many aspects. They are two separate code
> > paths that serve the same function, but they behave a little differently
> > under the hood.
> >
> >> Thanks again :)
> >
> > Wish I could have helped you recover the array. When a patient comes
> > through emergency with 3 GSWs to the forehead and no pulse, there's
> > nothing that can be done. :(
> >
> > --
> > Stan
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-08-05 12:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-27 12:16 Grub-install, superblock corrupted/erased and other animals Aaron Scheiner
2011-08-02 6:39 ` NeilBrown
2011-08-02 8:01 ` Stan Hoeppner
2011-08-02 16:24 ` Aaron Scheiner
2011-08-02 16:41 ` Stan Hoeppner
2011-08-02 21:13 ` Aaron Scheiner
2011-08-03 4:02 ` Stan Hoeppner
2011-08-02 16:16 ` Aaron Scheiner
2011-08-03 5:01 ` NeilBrown
2011-08-03 8:59 ` Aaron Scheiner
2011-08-03 9:20 ` NeilBrown
2011-08-05 10:04 ` Aaron Scheiner
2011-08-05 10:32 ` Stan Hoeppner
2011-08-05 11:28 ` Aaron Scheiner
2011-08-05 12:16 ` NeilBrown [this message]
2011-08-03 7:13 ` Stan Hoeppner
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=20110805221625.762f8415@notabene.brown \
--to=neilb@suse.de \
--cc=blue@aquarat.za.net \
--cc=linux-raid@vger.kernel.org \
--cc=stan@hardwarefreak.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).