From: Phil Turmel <philip@turmel.org>
To: Dave Gomboc <dave_gomboc@acm.org>
Cc: linux-raid@vger.kernel.org,
Adam Goryachev <mailinglists@websitemanagers.com.au>
Subject: Re: raid10 recovery assistance requested
Date: Sat, 28 Sep 2013 12:01:50 -0400 [thread overview]
Message-ID: <5246FD6E.2050105@turmel.org> (raw)
In-Reply-To: <CA+dwz-3DwwQ5_aCB8f8HJvKWqLGHF7-4BShe1QACnuzmXyo3KA@mail.gmail.com>
Hi Dave,
On 09/28/2013 11:47 AM, Dave Gomboc wrote:
>> 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.
I've never had to do this, but I would use the device mapper "snapshot"
target device. You could use it with a ram device, but I'd use another
partition in persistent mode. That way, once you succeed, you can merge
the result back into the real devices. Start with the device mapper
documentation in the kernel tree.
Phil
prev parent reply other threads:[~2013-09-28 16:01 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
2013-09-28 16:01 ` 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=5246FD6E.2050105@turmel.org \
--to=philip@turmel.org \
--cc=dave_gomboc@acm.org \
--cc=linux-raid@vger.kernel.org \
--cc=mailinglists@websitemanagers.com.au \
/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).