From: Eric Sandeen <sandeen@redhat.com>
To: Matteo Croce <technoboy85@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Massive filesystem corruption
Date: Sat, 20 Dec 2008 13:27:24 -0600 [thread overview]
Message-ID: <494D471C.8030907@redhat.com> (raw)
In-Reply-To: <200812201914.43614.technoboy85@gmail.com>
Matteo Croce wrote:
> Hi,
> i've lost my ext4 partition with a 2.6.27 vanilla kernel:
>
> root@ubuntu:~# mount -t ext4dev /dev/sda1 /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/sda1,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
What happened between the last successful mount and this failure?
> root@ubuntu:~# dmesg | tail -1
> [ 4874.514703] VFS: Can't find ext4 filesystem on dev sda1.
Was there anything before that? (i.e. check tail -n 10?)
What does the beginning of the fs look like, maybe you can put the first
16k or so of a dd somewehre, or run it through hexdump -C, see if
something else stomped on this partition.
> root@ubuntu:~# e2fsck /dev/sda1
> e2fsck 1.41.3 (12-Oct-2008)
> e2fsck: Superblock invalid, trying backup blocks...
> /dev/sda1 was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Error1: Corrupt extent header on inode 107192
> Aborted (core dumped)
> root@ubuntu:~# gdb -q --args e2fsck /dev/sda1
> (gdb) run
> Starting program: /sbin/e2fsck /dev/sda1
> [Thread debugging using libthread_db enabled]
> e2fsck 1.41.3 (12-Oct-2008)
> /sbin/e2fsck: Superblock invalid, trying backup blocks...
> /dev/sda1 was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Error1: Corrupt extent header on inode 107192
> [New Thread 0xb7e46700 (LWP 12878)]
>
> Program received signal SIGABRT, Aborted.
well, this was an explicit abort():
if (pctx->errcode) {
printf("Error1: %s on inode %u\n",
error_message(pctx->errcode), pctx->ino);
abort();
}
... I guess that error is not handled yet.
can you open the fs with debugfs, and try
debugfs> stat <107192>
and/or
debugfs> dump <107192> /some/path/to/dumpfile
and maybe we can see what's wrong with this inode. If it's the only one
then perhaps it can be nuked w/ debugfs and fsck will continue.
-Eric
next prev parent reply other threads:[~2008-12-20 19:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-23 5:49 (resend) extent header problems following shrink with resize2fs Paul Collins
2008-12-23 6:18 ` Theodore Tso
2008-12-20 18:14 ` Massive filesystem corruption Matteo Croce
2008-12-20 19:27 ` Eric Sandeen [this message]
2008-12-21 2:05 ` Matteo Croce
2008-12-21 3:23 ` Eric Sandeen
2008-12-21 5:09 ` Nick Dokos
2008-12-26 3:57 ` Theodore Tso
2008-12-25 7:18 ` (resend) extent header problems following shrink with resize2fs Paul Collins
2008-12-25 13:09 ` Theodore Tso
2008-12-26 4:14 ` Theodore Tso
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=494D471C.8030907@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=technoboy85@gmail.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.