Ext3 users - Nov 2001 - EXT3-fs error (device ide0(3,9)): ext3_readdir

Hi, 

yesterday I upgraded my kernel to 2.4.15-pre6 (after months of using
only ac-kernels) and had my first ext3-error since 0.0.3 .

syslog tells me :

Nov 20 18:16:31 enterprise kernel: EXT3-fs error (device ide0(3,9)):
ext3_readdir: bad entry in directory #47390: inode out of bounds -
offset=0, inode=404363549, rec_len=4096, name_len=23

and the system remounted /usr to ro.

I don't have any of raid, acl or anything else, just a plain ide drive.

So what should I do now ? Go to runlevel 1, umount /usr and run fsck ?
Remounting rw doesn't work :

root@enterprise:/ #mount -o remount,rw /usr 
mount: block device /dev/hda9 is write-protected, mounting read-only

and then in syslog:

Nov 20 19:47:04 enterprise kernel: ext3_abort called.
Nov 20 19:47:04 enterprise kernel: EXT3-fs abort (device ide0(3,9)):
		ext3_remount: Abort forced by user

As I already said, the first time ever I had any problems since the very
first versions. Thanks for your great work ! 

Cheers,

Dirk

On Nov 20, 2001  20:02 +0100, Dirk Pritsch wrote:
> yesterday I upgraded my kernel to 2.4.15-pre6 (after months of using
> only ac-kernels) and had my first ext3-error since 0.0.3 .
> 
> syslog tells me :
> 
> Nov 20 18:16:31 enterprise kernel: EXT3-fs error (device ide0(3,9)):
> ext3_readdir: bad entry in directory #47390: inode out of bounds -
> offset=0, inode=404363549, rec_len=4096, name_len=23
> 
> and the system remounted /usr to ro.
That does seem to be a bad inode number, unless you actually have 400M
inodes in this fs.  It seems somewhat strange in hex: 0x181a191d, so
not just a single bit error, and name_len=23 is 0x17, so also strange,
but rec_len seems OK.
> So what should I do now ? Go to runlevel 1, umount /usr and run fsck ?
Yes, always the best thing to do when having an ext2/ext3 problem,
unless you want to keep it around in case we need more data to try
and debug it.  What you might want to do is:

# unmount /usr
# script /tmp/e2fsck.log
# debugfs (device name)
debugfs> dump <47390> /tmp/bad_dir
debugfs> q

# od -Ax -tx4 -a /tmp/bad_dir
(od output here)

# e2fsck -f (device name)
(e2fsck output here)
# exit

and send the output to the list if it isn't too huge, otherwise some small
interesting parts are OK, or you could keep it in case of future need.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/