NFS performance: a question

[berliner at convex.UUCP]

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).

I decided to try your "cp 2 MegaBytes from client to server" timings
to see where we stand, and to see how the asynchronous server affects
the timings.  This is between two C-1's.  The results are as follows:

		| Sync.	| Async	|
	+-------+-------+-------+
	| Write	|  60kb	| 186kb	|
	| Read	| 204kb | 204kb	|
	+-------+-------+-------+

Note:  these numbers are completely unofficial and informal.  I'm just
reporting my quick timings.

I know that the "synchronous" nature of NFS relies on the fact that
once the server has responded to a write request, the client can rest
assured that the data is safely written to permanent storage.  That is
why our default behaviour is the "synchronous" one.  We document the
tradeoffs involved with turning on the asynch server option and leave
it to our customers to decide how they wish to use NFS.

I can tell you that internally, we run things with asynch NFS turned
on, due to the much improved performance we see on our writes.  I can
also tell you that you can only get burned if your server crashes --
we have not seen running async NFS server in-house to be a problem.

I might also note that the next revision of the NFS spec. (version 3)
seems to have some hooks to do just what we've done, but by adding it
into the spec.  There Sun may (it hasn't been released yet) add an NFS
request, WRITECACHE, which basically allows the client to control
which data is written to the server's buffer cache and whether or not
it should be "sync"ed to the disk upon completion.

Regards,

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Brian <nogger> Berliner				What is a nogger, anyway?
Convex Computer Corp.
UUCP: {ihnp4, uiucdcs, sun, rice, allegra}!convex!berliner
ARPA: convex!berliner at rice.arpa