Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!bloom-beacon!athena.mit.edu!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: comp.unix.wizards
Subject: Re: NFS performance: a question
Message-ID: <2965@bloom-beacon.MIT.EDU>
Date: 15 Feb 88 05:49:52 GMT
References: <663@noao.UUCP> <63500011@convex> <5432@cit-vax.Caltech.Edu> <41894@sun.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Organization: Massachusetts Institute of Technology
Lines: 24

In article <41894@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>It doesn't, at least in Sun's implementation; writes are synchronous on the
>server, but not on the client.  The "biod" processes handle asynchronous NFS
>writes.  Note that this has the disadvantage that write errors are not
>synchronously reported back to the program doing the "write"s; when doing NFS
>writes, "out of space" errors are not synchronously reported.  A program
>should probably do an "fsync" after writing out a lot of data, and check
>the return code from "fsync", so that it can find out about such errors
>and report them to the user.

In at least one version of NFS based on the Sun source (the Wisconsin
4.3+NFS for vaxen which we're using here at Athena), 99% of the code
needed to report write errors back to the client process was there.
However, the part which stored the error code from the write RPC call
into the rnode structure (the client side per-file state) was missing,
and thus fsync() and close() of NFS files could never return error
codes.

By the way, the biod's seem to be a very expensive way to implement a
`window'; that is, having one process per outstanding write packet.
If the Sun RPC client and server code could handle more than one
outstanding packet at a time, this could be fixed.

					- Bill