Re: Latest ext2fs Failure
> I build in a separate file partition (hd0s3). The root Hurd filesystem
> (with all libraries and system binaries) is located
> in /dev/hd0s2.
I take it from your account that the heavy disk activity was on hd0s3, but
you saw corruption on hd0s2. Is that right? Did you see any signs of
corruption on hd0s3 as well? (If e2fsck doesn't detect anything, you can
search for directory corruption by doing `ls -R /dir' and waiting for the
other shoe to drop.)
> I booted into Linux, and mounted my hurd partition to have a look.
Make sure you mount read-only, and that e2fsck doesn't run automatically at
boot. Also, what Linux kernel version are you using?
> ext2-fs error (device 03:02): ext2_readdir: bad entry in directory
> #122881: rec_len is too small for name_len -- offset = 140, inode = 122887,
> rec_len = 20, name_len = 28169.
>
> ext2-fs error (device 03:02): ext2_readdir: bad entry in directory
> #122881: rec_len is too small for name_len -- offset = 140, inode =
> 1970238055, rec_len = 11632, name_len = 13106.
?? What's this about? It's reporting two different sets of bogus contents
at the same spot in the same directory (140 bytes into in #122881). I'm
pretty confused about how this could be, unless Linux rewrote its own
different bogons into the directory between the first and second messages.
> ext2-fs error (device 03:02): ext2_readdir: bad entry in directory
> #192513: rec_len is too small for name_len -- offset = 388, inode =
> 192538, rec_len = 24, name_len = 25871.
Ack. Well, this little patch to ext2fs adds an assert that should trip if
the Hurd is writing these bogons in the simplest way, but I am pretty
doubtful that this will catch the actual bug. It is already the case that
the Hurd's ext2fs should print "bad directory entry" warnings if it ever
comes across bogons like this on the disk. Off hand the only pithy thing I
can find to say about these two directories is that each resides in the
first inode in its block group, but I can't imagine why that would explain
anything.
Index: dir.c
===================================================================
RCS file: /afs/sipb.mit.edu/project/hurddev/cvsroot/hurd/ext2fs/dir.c,v
retrieving revision 1.37
diff -u -b -p -r1.37 dir.c
--- dir.c 1999/10/03 23:31:58 1.37
+++ dir.c 1999/10/12 18:58:47
@@ -640,6 +640,7 @@ diskfs_direnter_hard (struct node *dp, c
#endif
new->name_len = namelen;
memcpy (new->name, name, namelen);
+ assert (new->rec_len >= EXT2_DIR_REC_LEN (new->name_len));
/* Mark the directory inode has having been written. */
dp->dn->info.i_flags &= ~EXT2_BTREE_FL;
> Running e2fsck did not reveal anything interesting. I do not
> understand how this can be, since the directory entries are so
> screwed up:
e2fsck does not check every possible form of inconsistency, so it is
certainly possible for a buggy ext2fs to scribble the filesystem in a way
that e2fsck would not notice. However, I am somewhat bewildered in this
case, because it appears to me that e2fsck's Pass 2 checks should catch
these very problems (I am looking at e2fsprogs-1.15): specifically, it
checks for offset+rec_len > blocksize, and 140+11632 is more than 1024 last
I checked (but that rec_len is from the curious second error message above,
and the first error message for the same inode shows a rec_len/name_len
that would not trip e2fsck). (It is also the case that e2fsck doesn't
really check this as thoroughly as it could. The large name_len values are
clearly bogus, but e2fsck only looks at the low 8 bits of name_len; it
ought to insist that the high bits be zero if the FILETYPE feature flag is
not set in the superblock.)
> I am attaching the output from dumpe2fs, which doesn't mean a whole
> lot to me, but might help Roland.
Thanks, it's always good to have that. Unfortunately it doesn't tell me
very much in this case. dumpe2fs only shows the superblock and block group
(allocation) information. That does show me that both inodes referenced in
the bogus directory entries (122887 and 192538) are valid, allocated inodes.
It might give further clues to see what files those inodes are, and if
their contents look ok.
> I also fired up debugfs and looked at the various directories. The
> strange thing is the debugfs could read the directory entries just
> fine.
debugfs can be more useful in trying to figure it out. (Also, I don't know
what your cpu/connectivity situation is or how big your partition is, but
if you can dd the whole partition off, bzip2, and put that on the net for
me to fetch, then I can take a look at your damaged filesystem directly.)
It would be helpful to show me what debugfs's `ls' shows for the
directories in question (i.e. "ls <122881>", "ls <192513>"); it shows the
rec_len values. You can use debugfs's `dump' to fetch the raw contents of
the corrupted directories into a file, and send me that; also use it to
fetch the raw contents of the referenced inodes and (122887, 192538) and
look at them or use `file' or whatever to figure out what they are and if
they are intact.
Reply to: