From owner-freebsd-current Mon Nov 13 20:40:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA23419 for current-outgoing; Mon, 13 Nov 1995 20:40:47 -0800 Received: from hq.icb.chel.su (icb-rich-gw.icb.chel.su [193.125.10.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA23338 for ; Mon, 13 Nov 1995 20:39:55 -0800 Received: from localhost (babkin@localhost) by hq.icb.chel.su (8.6.5/8.6.5) id JAA19967; Tue, 14 Nov 1995 09:39:04 +0500 From: "Serge A. Babkin" Message-Id: <199511140439.JAA19967@hq.icb.chel.su> Subject: Re: ISP state their FreeBSD concerns To: terry@lambert.org (Terry Lambert) Date: Tue, 14 Nov 1995 09:39:03 +0500 (GMT+0500) Cc: karl@mcs.com, terry@lambert.org, current@FreeBSD.org In-Reply-To: <199511132041.NAA17961@phaeton.artisoft.com> from "Terry Lambert" at Nov 13, 95 01:41:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1723 Sender: owner-current@FreeBSD.org Precedence: bulk > > 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. I personally see a database on NFS absolutely not worth because it is much less effective than running SQL requests. For non-transaction oriented databases like dBASE this crash would be a "normal work". :-) > Client caching is disallowed by the NFS design document. :-( > 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. It can help for multiple processes accessing the files over NFS. If you have single process creating the main load this will not help. And this is one of the problems that make running NFS from DOS machines very ineffective. Serge Babkin ! (babkin@hq.icb.chel.su) ! Headquarter of Joint Stock Commercial Bank "Chelindbank" ! Chelyabinsk, Russia