linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Ohm <chr.ohm@gmx.net>
To: linux-ext4@vger.kernel.org
Subject: How to recover a damaged ext4 file system?
Date: Mon, 5 Jan 2009 14:53:47 +0100	[thread overview]
Message-ID: <20090105135347.GA3337@localdomain> (raw)


Hello,

Since ext4 had its development status removed in 2.6.28, and there seemed to be
no reports of serious problems, I decided to try it on a partition of
semi-important files. Well, after a hard system hang because of the (open
source Radeon) graphics driver, the file system is quite corrupted, and cannot
be mounted any more (that never happened with ext3). mount gives the following
error:

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg message:

EXT4-fs: ext4_check_descriptors: Block bitmap for group 0 not in group (block 727012683)!
EXT4-fs: group descriptors corrupted!

I have uploaded the output of fsck .ext4 -n at
http://www.filefactory.com/file/aff6f3g/n/fsck_ext4_bz2 which is over 6MB of
stuff like

---
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext4: Group descriptors look bad... trying backup blocks...
Block bitmap for group 0 is not in group.  (block 727012683)
Relocate? no

Inode bitmap for group 0 is not in group.  (block 3406175899)
Relocate? no

Inode table for group 0 is not in group.  (block 1236188664)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? no

Group descriptor 0 checksum is invalid.  Fix? no

Block bitmap for group 1 is not in group.  (block 2704710215)
Relocate? no

Inode bitmap for group 1 is not in group.  (block 2166870417)
Relocate? no

Inode table for group 1 is not in group.  (block 600148394)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate? no

Group descriptor 1 checksum is invalid.  Fix? no
---

and later

---
Group descriptor 7452 checksum is invalid.  Fix? no

Error reading block 1236188664 (Invalid argument).  Ignore error? no

data-1000 contains a file system with errors, check forced.
Error reading block 1236188664 (Invalid argument).  Ignore error? no

fsck.ext4: Invalid argument while reading bad blocks inode
This doesn't bode well, but we'll try to go on...
Pass 1: Checking inodes, blocks, and sizes
Illegal block number passed to ext2fs_test_block_bitmap #1236188664 for in-use block map
Illegal block number passed to ext2fs_mark_block_bitmap #1236188664 for in-use block map
---


Now as I said, the files are semi-important, meaning I could recover those I
still want with some time, but repairing the file system would be preferable.
Unfortunately I don't have enough space on another harddrive to just copy the
partition and experiment on that, so I haven't tried letting fsck repair the fs
yet, and since it says SEVERE DATA LOSS POSSIBLE I wouldn't like to try that
without copying first.

So my two main questions would be:

1. How can I recover the data on the file system? As I said, I don't need all
the files, but it would save some time. I created it with the mkfs.ext4 from
Debian unstable (1.41.3) with only largefile as extra option, and the default
mount options with kernel 2.6.28. The fs wasn't used for long, and I mostly
copied/created files, without deleting much.

2. Is this corruption a fault of ext4? I guess this is difficult to answer, but
I had ext3 survive any lockups without much problems. So far ext4 seems not
quite that robust, but perhaps another file system would have blown up as well
in this situation. Is there any information I can give you to help make ext4
more robust?

Best regards,
Christian Ohm

PS: I think my first post with the fsck output attached got rejected due to its
size, though I didn't receive a message about that.

             reply	other threads:[~2009-01-05 13:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 13:53 Christian Ohm [this message]
2009-01-06 12:05 ` How to recover a damaged ext4 file system? Andreas Dilger
2009-01-06 19:34   ` Theodore Tso
2009-01-07 21:42     ` Christian Ohm
2009-01-08 10:11       ` Andreas Dilger
2009-02-07 16:27     ` Christian Ohm
2009-02-07 19:04       ` Eric Sandeen
2009-02-12 21:36         ` Christian Ohm

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=20090105135347.GA3337@localdomain \
    --to=chr.ohm@gmx.net \
    --cc=linux-ext4@vger.kernel.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).