>Date: Fri, 08 Mar 1996 07:47:22 -0700
>To: current-users@NetBSD.ORG
>From: Trevin Beattie <trevin@xmission.com>
>Subject: Filesystem buffers in the kernel
>
>This question is directed to people who write the filesystem drivers.  What
should be the state of a 'struct buf' object both before and after the vnode
which used it is released?
>
>Scenario: when I mount a new filesystem type, I can list the directories
and read a file with no apparent problem (both the terminal output and
console output from printf checkpoints behave as expected).  After reading
the file I unmount the filesystem and run xless to view the
/var/log/messages file, only to find that xless is toast!  "head `which
xless`" produces the file I had read previously from the now-unmounted
filesystem.  Fortunately, if I reboot the kernel or fill the buffers with
something else, xless comes back; so the problem is all in the buffers.
>
>The only thing I can guess is that when I run xless it happens to take the
same 'struct vnode' object that the previous file was using, and the buffer
routines thought the 'struct buf' object for that vnode still had valid
data.  Why?
>

Never mind about the buffers; I followed the kern/ code and found the
problem.  FS_inactive calls vfs_subr.c:vgone(), which calls
vfs_subr.c:vinactive(), which calls FS_fsync, which in turn is supposed to
flush the file's inode to disk.  In this case, the flush failed (even though
the filesystem was mounted read-only!), and the error caused vinactive()
_not_ to invalidate the buffers associated with the vnode.  Even though the
error propagated all the way out of FS_inactive, FS_reclaim was still called
and the vnode died while buffers were still attached to it.

Now I just need to find a way to guarantee that FS_sync never returns an error.
-----------------------
Trevin Beattie          "Do not meddle in the affairs of wizards,
trevin@xmission.com     for you are crunchy and good with ketchup."
      {:->                                     --unknown