Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (Don Speck)
Newsgroups: comp.unix.wizards
Subject: Re: NFS performance: a question
Summary: wrong place to solve it
Message-ID: <5432@cit-vax.Caltech.Edu>
Date: 14 Feb 88 08:08:06 GMT
References: <663@noao.UUCP> <63500011@convex>
Organization: California Institute of Technology
Lines: 26

In article <63500011@convex>, berliner@convex.UUCP writes:
> At CONVEX, we have a special variable which can be patched on a running
> system (or built in during system configuration) which enables the
> CONVEX NFS server to operate asynchronously.	That is, to NOT do a
> synchronous write, but rather simply queue the write request in the
> buffer cache to be written to permanent disk storage at some later
> time (marked delayed-write).

This is unnecessarily risky; it could probably be handled better in
the client.  In conventional Unix filesystems, bufs for writing file
blocks are marked B_ASYNC, and nobody is waiting for them to complete;
so if the acknowledges are slow in coming, that shouldn't inhibit the
client from sending some more to the server.  The client should blast
data at the server until one of server or client cannot keep track of
more outstanding requests.  Unfortunately, the default limit on the
amount of unacknowledged outstanding requests is a mere 6K!  It may
help to raise this, if the server's ethernet board has enough buffering,
but what is really needed is two kinds of acknowledges, one that says
    "Your request is completed",
and a new one that says
    "I can accept another N kilobytes of requests"
(much like TCP's notion of a "window").  Having the latter would
obviate the need to specify rsize and wsize when mounting an
NFS filesystem.  Anyone who owns 3com's would appreciate that.

Don Speck   speck@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck