[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3_readdir error

On Aug 10, 2002  18:42 +1000, Martial Herbaut wrote:
> I am getting the following errors on /boot partition on a production 
> server running 2.4.18 kernel.
> -------------
> Aug 10 00:19:37 kernel: EXT3-fs error (device sd(8,1)): 
> ext3_readdir: bad entry in directory #2: rec_len is smaller than minimal - 
> offset=0, inode=0, rec_len=0, name_len=0
> /boot is not readable at all and attempt to do an ls will return the same 
> error.

This looks like it was trying to read some data and it got zero instead.

> attempts to force  an fsck on that mounted partition (not sure if if it ok 
> to umount /boot) results in fsck returning a segmentation fault.

It is a very bad idea to fsck a mounted filesystem.  You can try just
unmounting it and then running e2fsck on it (you probably have to stop
sysklogd because it keeps System.map open, maybe others if lsof shows

Have you rebooted this system since you got the error?  It may also be
that if a bad page was "read" in, that any further attempts to read this
chunk of data are being read from cache instead of from the disk.  This
is partly speculation though.

> here is an strace of fsck crashing.
> open("/dev/sda1", O_RDONLY|O_LARGEFILE) = 5
> lseek(5, 1024, SEEK_SET)                = 1024
> read(5, "\210\27\0\0\2^\0\0\263\4\0\0B(\0\0X\27\0\0\1\0\0\0\0\0"..., 1024) 
> = 1024

Reading the superblock, OK.

> lseek(5, 2048, SEEK_SET)                = 2048
> read(5, "\3\0\0\0\4\0\0\0\5\0\0\0\17\6\265\7\2\0\0\0\0\0\0\0\0\0"..., 
> 1024) = 1024

Reading the group descriptor table, OK.

> lseek(5, 5120, SEEK_SET)                = 5120
> read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) 
> = 1024

Reading the inode table, including the root inode (#2, which is what you
are having problems with).  Hard to tell if this is bad data or not, since
the inode #1 space may well be all zeros (128 bytes worth).  In any
case, the fact that e2fsck is crashing is bad, unless, of course, if it
is crashing because of a kernel oops, which is even worse.

What would be very useful is if you ran e2fsck under GDB and found where
it is crashing, so that this can be fixed.  You may have to download the
sources and build it yourself to get a version of e2fsck with debugging

You could try debugfs to see what is there, like (this may crash also,
but will do no harm):

# debugfs /dev/sda1
debugfs> stats
debugfs> stat <2>

Cheers, Andreas
Andreas Dilger

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]