Subject: Re: NFS buffer cache problem
To: None <rick@snowhite.cis.uoguelph.ca>
From: David Greenman <davidg@Root.COM>
List: netbsd-bugs
Date: 02/02/1995 19:54:20
>While banging away at NFS v3 I ran into this little problem w.r.t. buffer
>cache semantics for FreeBSD2.0R. The attached code is meant to write the
>dirty area back to the server and then invalidate the buffer. The 4.4BSD-Lite
>code (nfs_bio.c.bak) worked with the 4.4BSD buffer cache, but for FreeBSD2.0R
>the write was just thrown away. There was also a race when another process
>did a getblk() for the same block and would allocate a new one before the
>write completed. For the FreeBSD2.0R buffer cache code the fix is to simply
>use the B_NOCACHE flag instead of the B_INVAL flag. Does the same fix seem
>appropriate for the other 4.4BSD-Lite descendants?
>
>In the FreeBSD2.0R getblk() there is also the possibility of a race when
>two processes try to get a block for the same file at the same time and
>one ends up sleeping in getnewbuf(), but admittedly the likelyhood of this
>actually happening is pretty slim:-)

   The vfs_bio.c in post 2.0 has been almost completely rewritten to implement
the merged VM/buffer cache. There was a different bug related to not properly
disposing of data in the page cache with B_NOCACHE buffers, but I just
committed a fix for that a few minutes ago. The getblk() race was fixed a
month or so ago.
   Since NFS is stateless, it required a few minor changes to support the
merged cache scheme - all related to running down resources at the appropriate
time. I suspect that the NFS v3 code will require a small amount of change
before it will work correctly with 2.1. I'm very interested in this, and am
willing to help with the integration of the changes. We can also provide you
with the ability to manage these changes directly in our CVS tree if you are
interested.

-DG