All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: George Spelvin <linux@horizon.com>
Cc: dreusser@gmail.com, linux-ext4@vger.kernel.org
Subject: Re: Issue with bad file system
Date: Mon, 19 Nov 2012 09:29:01 -0600	[thread overview]
Message-ID: <50AA503D.2060503@redhat.com> (raw)
In-Reply-To: <20121119083245.18044.qmail@science.horizon.com>

On 11/19/12 2:32 AM, George Spelvin wrote:
...

> "e2fsck -n" will only print errors and not change anything.  It's
> always safe.
> 
> Try "e2fsck -n -v /dev/md0" (given the dumpe2fs failure, I expect that
> will not work) and then try "e2fsck -n -v -b 32768 /dev/md0".
> 
> I don't know what happened to your superblock, but if that's all that
> got trashed, recovery is actually quite straightforward and there's no
> risk of data loss.  e2fsck will just print a huge number of "free blocks
> count wrong" messages as it fixes them.
> 
> (However, that's a pretty big "if".)
> 
> 
> Another thing that would be useful is "dd if=/dev/md0 skip=2 count=2 | xxd"
> (or od -x if you don't have xxd).  That will give a hex dump of the
> primary superblock, which might show the extent of the damage.
> 
> 
> If "e2fsck -n -b 32768" works, the way to repair it is to run it again
> without the "-n", but the -n output will say how bad it is.

Whoops, I replied without seeing these other replies; somehow threading
was broken w/ George's first reply.

Anyway - I would not go to e2fsck yet.  I think your raid is mis-assembled.
I'd investigate that first.  I'll look at the other output a bit more, but
for now, I'd stay away from fsck - just wanted to get that out there quick.

-Eric

  reply	other threads:[~2012-11-19 15:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19  6:30 Issue with bad file system George Spelvin
2012-11-19  7:23 ` Drew Reusser
2012-11-19  8:32   ` George Spelvin
2012-11-19 15:29     ` Eric Sandeen [this message]
2012-11-19 17:00       ` Drew Reusser
2012-11-19 16:57     ` Drew Reusser
2012-11-19 17:14       ` Eric Sandeen
2012-11-19 18:41         ` Theodore Ts'o
2012-11-19 19:15           ` George Spelvin
2012-11-19 19:36             ` Theodore Ts'o
2012-11-19 19:53           ` Drew Reusser
2012-11-19 20:24             ` Theodore Ts'o
2012-11-19 19:54         ` Drew Reusser
2012-11-19 21:15           ` George Spelvin
2012-11-19 21:30             ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2012-11-19  4:46 Drew Reusser
2012-11-19 15:18 ` Eric Sandeen

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=50AA503D.2060503@redhat.com \
    --to=sandeen@redhat.com \
    --cc=dreusser@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux@horizon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.