From: Ed Tomlinson <edt@aei.ca>
To: nicholas.dokos@hp.com
Cc: linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: Ext4 corruption that will not go away
Date: Sun, 30 Aug 2009 19:19:55 -0400 [thread overview]
Message-ID: <200908301919.56608.edt@aei.ca> (raw)
In-Reply-To: <28421.1251642296@gamaville.dokosmarshall.org>
On Sunday 30 August 2009 10:24:56 Nick Dokos wrote:
> > Hi,
> >
> > I am running 2.6.31-rc8+ and have ext4 corruption that will not go away.
> >
> > My root fs is ext4 on sdb3. I have moved the directory with corruption into lost+found and booted to a rescuse
> > system (arch linux) and run fsck.ext4 on the filesystem, which then reports its clean... Booting back into my
> > gentoo system and attempting to remove the xx directory from lost+found gives:
> >
> > [ 172.408799] EXT4-fs error (device sdb3): ext4_ext_check_inode: bad header/extent in inode #706801: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
> > [ 172.429410] EXT4-fs error (device sdb3): ext4_ext_check_inode: bad header/extent in inode #706801: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
> > [ 172.449920] EXT4-fs error (device sdb3): ext4_ext_check_inode: bad header/extent in inode #706801: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
> >
> > The above is repeatable.
> >
> > How can I _really_ clean this fs? What info is needed to help the process?
> >
>
> The first two pieces of information needed would be the version of e2fsprogs
> that you are running (e2fsck -V) and the stat of inode 706801:
>
> debugfs -R 'stat <706801>' /dev/sdb3
>
e2fsck 1.41.9 (22-Aug-2009)
Using EXT2FS Library version 1.41.9, 22-Aug-2009
Inode: 706801 Type: regular Mode: 0644 Flags: 0x80000
Generation: 28075061 Version: 0x00000000:00000001
User: 0 Group: 0 Size: 1442
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4a8beb6a:a8c2e6e4 -- Wed Aug 19 08:09:14 2009
atime: 0x4a8beb6a:00000000 -- Wed Aug 19 08:09:14 2009
mtime: 0x4a8b17d9:00000000 -- Tue Aug 18 17:06:33 2009
crtime: 0x4a8beb6a:9e456724 -- Wed Aug 19 08:09:14 2009
Size of extra inode fields: 28
EXTENTS:
and of 76804 which also has a problem
Inode: 706804 Type: regular Mode: 0644 Flags: 0x80000
Generation: 4140131203 Version: 0x00000000:00000001
User: 1000 Group: 100 Size: 523
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4a95c957:348db0b8 -- Wed Aug 26 19:46:31 2009
atime: 0x4a991f2b:cf3a606c -- Sat Aug 29 08:29:31 2009
mtime: 0x4a95c957:348db0b8 -- Wed Aug 26 19:46:31 2009
crtime: 0x4a95c957:348db0b8 -- Wed Aug 26 19:46:31 2009
Size of extra inode fields: 28
EXTENTS:
Hope this helps
Ed
next prev parent reply other threads:[~2009-08-30 23:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-17 18:43 Ext4 tree backports for 2.6.27.10 and 2.6.28 Theodore Ts'o
2009-01-17 22:16 ` ext4-stable build failure (Re: Ext4 tree backports for 2.6.27.10 and 2.6.28) Malte Schröder
2009-01-17 23:03 ` Theodore Tso
2009-01-17 23:03 ` Theodore Tso
2009-01-19 11:33 ` Ext4 tree backports for 2.6.27.10 and 2.6.28 Aneesh Kumar K.V
2009-08-30 4:25 ` Ext4 corruption that will not go away Ed Tomlinson
2009-08-30 13:15 ` LDB
2009-08-30 14:24 ` Nick Dokos
2009-08-30 23:19 ` Ed Tomlinson [this message]
2009-08-30 15:41 ` Theodore Tso
2009-01-19 11:33 ` Ext4 tree backports for 2.6.27.10 and 2.6.28 Aneesh Kumar K.V
2009-01-19 11:34 ` [PATCH] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize Aneesh Kumar K.V
2009-01-19 11:35 ` [PATCH] ext4: Use an rbtree for tracking blocks freed during transaction Aneesh Kumar K.V
2009-01-19 17:14 ` Mike Snitzer
2009-01-19 17:16 ` Mike Snitzer
2009-01-19 11:36 ` [PATCH] ext4: don't use blocks freed but not yet committed in buddy cache init Aneesh Kumar K.V
2009-01-19 11:38 ` [PATCH]ext4: Use new buffer_head flag to check uninit group bitmaps initialization Aneesh Kumar K.V
2009-01-19 11:39 ` [PATCH] ext4: Add blocks added during resize to bitmap Aneesh Kumar K.V
2009-01-22 19:50 ` [stable] Ext4 tree backports for 2.6.27.10 and 2.6.28 Greg KH
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=200908301919.56608.edt@aei.ca \
--to=edt@aei.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicholas.dokos@hp.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.