On Sat, Dec 15, 2012 at 11:08:34PM -0700, Andreas Dilger wrote:
> > debugfs 1.41.12 (17-May-2010)
> > Level Entries Logical Physical Length Flags
> > 0/ 0 1/ 1 0 - 4294967295 37333026 - 4332300321 0
>
> This is interesting. The one extent reports it is valid for 2^32-1
> blocks, but this isn't possible with the current on-disk extent
> format. It looks like the extent is actually storing "-1" blocks
> (which is also invalid) but is incorrectly sign extended to
> 0xffffffff.
Actuually, the number of blocks in the extent was set to 0. The
number reported by e2fsprogs contains is the inclusive range (i.e.,
lblk, lblk+len-1).
A fix for this was added to e2fsprogs in v1.42.2 in March 2012, by
commit 26c09eb8145a1 ("e2fsck: check for zero length extent"). There
was a regression which this commit would sometimes trigger which was
fixed in v1.42.4 (commit 9c40d14841f0, "e2fsck: only check for
zero-length leaf extents"). So e2fsck 1.42.4 or newer is recommended
to repair this sort of file system corruption.
> > Ok. The problem is that I'm trapped. I need to compile the most
> > recent version (1.42.6) but the needed file to
> > compile (/usr/include/dlfcn.h) isn't available (Input/output error)
> > because of this problem.
What I would suggest that you do is to zap the bad inode and then run
e2fsck to repair the resulting damage:
debugfs -w -R "clri <9311628>" /dev/sda2
e2fsck -fy /dev/sda2
Then reinstall the glibc package (libc6-dev if you are using a
Debian-derived distribution), which supplies dlfcn.h, and then
recompile e2fsprogs so you can install a 1.42.x version of e2fsprogs.
I'm not entirely sure how the inode had gotten corrupted in the first
place, but I would be surprised if it was due to upgrading the kernel
from 3.6 to 3.7. If you do see this corruption again, please let us
know, and hopefully we can try to figure out what the root cause of
the issue might be.
Regards,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
