From: Dave Gomboc <dave_gomboc@acm.org>
To: Phil Turmel <philip@turmel.org>, linux-raid@vger.kernel.org
Cc: Adam Goryachev <mailinglists@websitemanagers.com.au>
Subject: Re: raid10 recovery assistance requested
Date: Sat, 28 Sep 2013 15:47:35 +0000 [thread overview]
Message-ID: <CA+dwz-3DwwQ5_aCB8f8HJvKWqLGHF7-4BShe1QACnuzmXyo3KA@mail.gmail.com> (raw)
In-Reply-To: <CA+dwz-0Y6+778sPHKn90B6dPNUyC7E__vhzR3BpeKaUgJQumqg@mail.gmail.com>
> fsck.ext3 -n /dev/mapper/teramooch-srv
> e2fsck 1.42.7 (21-Jan-2013)
> ext2fs_open2: Bad magic number in super-block
> fsck.ext3: Superblock invalid, trying backup blocks...
> fsck.ext3: Bad magic number in super-block while trying to open
> /dev/mapper/teramooch-srv
So, I am now restoring the content of the two drives that I altered
(by running ddrescue again) , so that I have all four drives copied as
before.
If each pair of two drives genuinely have the same information on
them, then I only seem to have that one method of array assembly
available to me, in which case I suppose I will need to try to scan at
a lower level, searching for parts of the ext3 filesystem of the
logical volume that I cannot mount. I could certainly use some advice
on what might be worth trying in this scenario. Even if I can't get
everything back, I should try to get anything back that I can.
However, if there is some variation between what two drives that
report place '0' (or the two drives that report place '3') are
actually holding, then I have more array assembly options to try
before dealing with the above issue.
Is there already some software out there (or do you think it would not
be particularly difficult for an experienced software developer who
does not have extensive knowledge of linux internals -- such as myself
:-) that could be used to treat the physical drives as read-only, and
do any "writes" to them to a layer in RAM instead? That is, it would
read from RAM first, then from the disk only if nothing was present in
RAM, and always leave the contents of the disks unchanged when writing
back to RAM (never writing through to disk)? If I had something like
that, I could make various attempts, then discard the changes easily
after failed tries, without having to restore the hard drive contents
from the actual original drive afterwards Of course, I don't have
several terabytes of RAM, but I think there is really only a small
portion of the disk that is being edited when I am doing various
operations such as mdadm --assemble and vgchange.
Dave
next prev parent reply other threads:[~2013-09-28 15:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 3:30 raid10 recovery assistance requested Dave Gomboc
2013-09-19 3:20 ` Dave Gomboc
2013-09-19 4:29 ` Stan Hoeppner
2013-09-20 5:29 ` Dave Gomboc
2013-09-22 17:15 ` Dave Gomboc
2013-09-22 21:52 ` Phil Turmel
2013-09-22 22:45 ` Dave Gomboc
2013-09-22 23:04 ` Dave Gomboc
2013-09-22 23:25 ` Phil Turmel
[not found] ` <CA+dwz-0eskPSQ44v0vgwfjwRpTbQaokQ3Q258Em1W2eRi1SO4w@mail.gmail.com>
2013-09-23 2:54 ` Phil Turmel
2013-09-23 3:19 ` Dave Gomboc
2013-09-23 3:27 ` Phil Turmel
2013-09-23 3:34 ` Dave Gomboc
2013-09-23 3:51 ` Phil Turmel
2013-09-23 4:04 ` Dave Gomboc
2013-09-23 4:12 ` Phil Turmel
2013-09-23 4:55 ` Dave Gomboc
2013-09-23 5:07 ` Dave Gomboc
2013-09-23 5:19 ` Adam Goryachev
2013-09-23 12:32 ` Phil Turmel
2013-09-23 12:57 ` Dave Gomboc
2013-09-24 0:29 ` Adam Goryachev
2013-09-24 5:55 ` Dave Gomboc
2013-09-28 15:47 ` Dave Gomboc [this message]
2013-09-28 16:01 ` 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=CA+dwz-3DwwQ5_aCB8f8HJvKWqLGHF7-4BShe1QACnuzmXyo3KA@mail.gmail.com \
--to=dave_gomboc@acm.org \
--cc=linux-raid@vger.kernel.org \
--cc=mailinglists@websitemanagers.com.au \
--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).