From owner-freebsd-current Tue Nov 14 09:26:29 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23975 for current-outgoing; Tue, 14 Nov 1995 09:26:29 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA23959 for ; Tue, 14 Nov 1995 09:26:23 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20197; Tue, 14 Nov 1995 10:18:27 -0700 From: Terry Lambert Message-Id: <199511141718.KAA20197@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: babkin@hq.icb.chel.su (Serge A. Babkin) Date: Tue, 14 Nov 1995 10:18:27 -0700 (MST) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.org In-Reply-To: <199511140439.JAA19967@hq.icb.chel.su> from "Serge A. Babkin" at Nov 14, 95 09:39:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2253 Sender: owner-current@FreeBSD.org Precedence: bulk > > 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". :-) I was thinking more in terms of an "email database". It wants the write guarantees to be honored so the locking protocol functions correctly. > > 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. The other being lack of long file name support and DOS's inability to operate multiple I/O instances and/or drives as multiple session instances and issue async requests. DOS has the same problem with NetWare or SMB, both of which are request/response in nature. Another request can't be issued until the previous one is satisfied. NetWare has fixed windows for binary downloads ("packet burst") to partly alleviate the problem in trade for congesting the bejesus out of your network in certain circumstances. OS/2 fixes this by using seperate sessions. As does NT and Windows95. I think I've seen a Win3.1 client that did this as well. The easy answer is: don't use DOS, it sucks. I think the issue was multple news reader processes and I/O being bottlenecked by requestst being queued for too few service engines. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.