Understanding fsck.ext3 errors

DigitalMagnets · 10-03-2007, 07:30 AM

The problem all started when I noticed that df -h wasn't reporting space properly on a spare backup drive I have mounted.

So I umounted it and ran fsck.ext3, which showed lots of errors about ref count being 2, should be 1 etc. I let it run for a while and then decided it'd be quicker to reformat and copy the data over again, which I did.

Now on the clean ext3 drive, with all the data copied back onto it, the space is being reported properly by df BUT, on doing fsck.ext3, I get this output:

Quote:

/sbin/fsck.ext3 -f /dev/sdb1
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Inode 11487123 is too big. Truncate<y>? no

Block #8193 (22980741) causes directory to be too big. IGNORED.
Block #8194 (22980742) causes directory to be too big. IGNORED.
.....
Block #8202 (22980750) causes directory to be too big. IGNORED.
Block #8203 (22980751) causes directory to be too big. IGNORED.
Too many illegal blocks in inode 11487123.

Here is the tune2fs output for the drive:

Quote:

tune2fs 1.35 (28-Feb-2004)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 19546112
Block count: 39072080
Reserved block count: 1953604
Free blocks: 28046146
Free inodes: 18106874
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Wed Oct 3 01:51:45 2007
Last mount time: Wed Oct 3 01:54:49 2007
Last write time: Wed Oct 3 12:50:34 2007
Mount count: 1
Maximum mount count: -1
Last checked: Wed Oct 3 01:54:42 2007
Check interval: 15552000 (6 months)
Next check after: Mon Mar 31 01:54:42 2008
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: eb10dd05-d139-4eee-9c65-3448ca2730d2
Journal backup: inode blocks

The drive has around 2 million files copied to it from the primary drive. These files are 25% each 1-200k, 30k, 5k, 2k. They are all stored in one directory.

I've tried to read up on the errors outputted by fsck but can find very few instances of others having this problem.

DigitalMagnets · 10-03-2007, 08:45 AM

After doing some more research, I've found how to find which directory / file the Inode that is too big is. Suprise suprise, it's the directory with around 2 million files in it.

Doing a ls -lh of the directory the large directory is in, shows that it is 84m for the directory information itself (around 40gigs for the total files inside it).

Now I just need to work out how to change the directory size limit don't I?

DigitalMagnets · 10-03-2007, 09:31 AM

Having a good convo with myself here...

I seem to have found the problem. I was running an old version of e2fsprogs - v1.35 (includes fsck.ext3), which is the latest available on Centos 4.5 yum. I have downloaded and installed e2fsprogs v1.40.2 which doesn't find any errors.

My only remaining question is, is it safe to overwrite Centos's e2fsprogs with the latest release from sourceforge? I'm a bit worried as it seems quite an integral part of the system to update in this manner. Though having said that, v1.35 was essentially corrupting data so...

ghostdancer · 10-03-2007, 10:07 AM

Just curious, if you are aware the distro you are using is an older version, why not upgrade to the latest version?

It is always possible to upgrade very utilities and programs manually (for new version of your distro, the developers that did this for you), but it can be very troublesome if you are not prepare to handle it.