Date: Mon, 13 Nov 1995 13:41:13 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: karl@mcs.com (Karl Denninger, MCSNet) Cc: terry@lambert.org, current@FreeBSD.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511132041.NAA17961@phaeton.artisoft.com> In-Reply-To: <m0tF4YE-000IDUC@venus.mcs.com> from "Karl Denninger, MCSNet" at Nov 13, 95 01:28:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The only other issue we have here is the nasty NFS-write problem that makes > > > shared access to remote resources tricky at best. If *THAT* was fixed we > > > would be running FreeBSD exclusively here. > > > > Is this the "write with no permission truncate" or what? What is this > > NFS write problem? > > The symptom is that processes block while waiting for writes to complete, > sometimes for as long as several *minutes*. For a system which is taking > hundreds of hits per minute, this quickly blows the system sky-high. Ah. So the hangs are on the client. The NFS protocol definition is that the writes must complete before the call returns to the user process. There are three ways to solve this problem: 1) Client caching. The operation writes local cache and then starts an async event with a completion routine. The async event waits for the ack from the NFS server and releases the page hold. This is dangerous, since the data pretends to be committed when in fact it only exists in the local systems memory. Not a problem for news servers, but a real problem for transaction oriented databases. Client caching is disallowed by the NFS design document. 2) Server caching. The operation is returned completed by the server, which then starts an async event, but no completion routine is associated with the event. This is dangerous for similar reasons of data integrity. Server caching is disallowed by the NFS design document unless the state can be maintained across a server failure. This means log structuring with log data sotred in non volatile memory (ala Auspex, etc.) so the transaction may be rolled forward. 3) Increase the number of nfsiod's on the server. This will allow more concurrent operations to be outstanding at one time. This is allowed (encouraged) by the NFS design document. Number 3 is well within your control. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511132041.NAA17961>