Date: Fri, 27 Sep 1996 23:34:07 +0200 (MET DST) From: guido@gvr.win.tue.nl (Guido van Rooij) To: terry@lambert.org (Terry Lambert) Cc: pst@shockwave.com, FreeBSD-hackers@freebsd.org Subject: Re: cvs commit: src/sbin/fsdb fsdb.c Message-ID: <199609272134.XAA02422@gvr.win.tue.nl> In-Reply-To: <199609272124.OAA10412@phaeton.artisoft.com> from Terry Lambert at "Sep 27, 96 02:24:07 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > This FS *was* fsck'ed after a crash, or it *wasn't* fsck'ed after a > crash? > > If it *wasn't*, then the loop was created in the FS code. > > If it *was*, then the fsck code is faulty. Indeed. It *is* fsck. > > So: can you tell me if the condition resulted from fsck not catching > it after a crash, or if it resulted from normal operation of the FS? > The first. I cannot come up with a scheme in which the FS could create such a directory (in the inode, some references to data blocks are null. fsck does not check non-present blocks and thus the FS passes fsck. The kernel does do the check and finds all zero's and thus all zero chunks where an empty chunk should have it's first byte set to 255). I believe that when adding directory entries, the FS code first allocates a new block (if necessary), update it and then changes the size of the inode. So I have no idea how the situation I sketched above could happen from within the FS code. I just posted a patch that is not yet complete but will at least do the trick. A better one will come in a few days. -Guido
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609272134.XAA02422>