[1017] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

Re: more scsi errors :(

daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Mon Nov 25 11:25:57 1996

Date: 	Mon, 25 Nov 1996 10:58:43 -0500
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jon Lewis <jlewis@inorganic5.fdt.net>
Cc: Gerard Roudier <groudier@club-internet.fr>, ncr53c810@colorado.edu,
        Linux SCSI Mailing List <linux-scsi@vger.rutgers.edu>
In-Reply-To: Jon Lewis's message of Sun, 24 Nov 1996 00:14:57 -0500 (EST),
	<Pine.LNX.3.95.961123154311.174A-100000@inorganic5.fdt.net>


   Date: 	Sun, 24 Nov 1996 00:14:57 -0500 (EST)
   From: Jon Lewis <jlewis@inorganic5.fdt.net>


   In my news server running 2.0.25 with a pair of NCR 810's using the BSD
   ported driver, I just noticed these in the kernel message buffer.

   EXT2-fs error (device 08:31): ext2_find_entry: bad entry in directory
   #757318: rec_len % 4 != 0 - offset=1552, inode=3941569338, rec_len=43694,
   name_len=16580

   I'm a bit confused by the messages...especially inode=3941569338.  I have
   a lot of inodes...but not that many.

The specifics of the error message is that directory entry in directory
inode 757318, offset 1552 (which means it's in the second block of the
directory) has gototen corrupted.  The record length and the name
lengths in the directory entry are obviously nonsensical (they can't
exceed 1024 under any circumstances) and so it's not surprising that the
inode number in the directory entry is also garbage.

   At some point, I'll probably kill innd, umount sdd1, run e2fsck -fy
   on it, remount, and restart innd.

Good idea.  Better to do it sooner rather later.  The presense of this
error indicates at least some filesystem corruption, and it's better to
catch this now rather than later.

What is still a mystery, of course, is *why* you have the filesystem
corruption.  It could be hardware related (and you seem to be exploring
those).  Besides a SCSI cabling problem, it could also be a wierd memory
bug, or some kind of kernel bug (somewhat less likely given that I
haven't seen anyone else report similar problems using the 2.0 kernels).

							- Ted

home help back first fref pref prev next nref lref last post