From owner-freebsd-hackers  Fri Sep 27 12:04:24 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA07479
          for hackers-outgoing; Fri, 27 Sep 1996 12:04:24 -0700 (PDT)
Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA07419
          for <FreeBSD-hackers@freebsd.org>; Fri, 27 Sep 1996 12:04:20 -0700 (PDT)
Received: by gvr.win.tue.nl (8.6.13/1.53)
    id VAA01907; Fri, 27 Sep 1996 21:04:08 +0200
From: guido@gvr.win.tue.nl (Guido van Rooij)
Message-Id: <199609271904.VAA01907@gvr.win.tue.nl>
Subject: Re: cvs commit: src/sbin/fsdb fsdb.c
To: pst@shockwave.com (Paul Traina)
Date: Fri, 27 Sep 1996 21:04:07 +0200 (MET DST)
Cc: FreeBSD-hackers@freebsd.org (FreeBSD-hackers)
In-Reply-To: <199609271648.JAA07942@precipice.shockwave.com> from Paul Traina at "Sep 27, 96 09:48:02 am"
X-Mailer: ELM [version 2.4ME+ PL17 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Paul Traina wrote:
> I just got a panic off of a 24-Sep kernel in:
> 
> #0  0xf011389e in boot ()
> #1  0xf0113b8a in panic ()
> #2  0xf01b28ab in ufs_dirbad ()
> #3  0xf01b205c in ufs_lookup ()
> #4  0xf013403e in lookup ()
> #5  0xf0133b0d in namei ()
> #6  0xf0139c05 in vn_open ()
> #7  0xf0137249 in open ()
> #8  0xf01d0db6 in syscall ()
> #9  0xf01c8275 in Xsyscall ()
> 
> I completely missed the comments about sparse directory panics.  When was this
> found/fixed?

Well, I had a filesystem with that behaviour. When I found out the cause
I contacted Kirk. He agreed with my diagnosis, but it was low on his
priority list so i made a fix. However, this fix is not what we really want.

The strange thing is that this should be impossible to happen. Anyway,
the problem is that sometimes an filesystem passes the fsck but still makes
the kernel panic with a bad dir: mangled entry (or something like that).
The reason is that the size of the directory is beyond the last datablock,
thus effectively making a sparse directory file (at least in my case).
Fsck doesn't find anything becuase it only examines the present datablocks.
The kernel does see such a non-present block as a bunch of zero's. And
that causes the panic because a non-used directory chunk should have a
reclen field of 255. The fix (until fsck is fixed) is to fsdb the filesystem,
chdir to the bad dir and do an ls. You will then see the last entry and you
can reset the size of the directory untill just after that entry.

-Guido