Date: Wed, 15 Nov 1995 08:59:39 +0500 (GMT+0500) From: "Serge A. Babkin" <babkin@hq.icb.chel.su> To: terry@lambert.org (Terry Lambert) Cc: terry@lambert.org, karl@mcs.com, current@FreeBSD.ORG Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511150359.IAA01506@hq.icb.chel.su> In-Reply-To: <199511141718.KAA20197@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 95 10:18:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > > 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.
The closing of file may be used as an implicit "sync" request for this file,
IMHO it should help for UUCP-like locking.
Or if they use fsync() it is an explicit request to "sync" the file. Are
there some other locking methods ?
> > > 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.
Async requests need more buffers and the main DOS idea is "save this 1K
or die".
> 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.
But the syncronous writes in NFS makes wery big overhead. The write throughput
for DOS and different networking systems is like (on empty network):
Netware - about 700 K/s (may be Netware client has more buffers ? but it takes
less of memory than NFS client)
BSDI NFS - about 300K/s
HP/UX 9.04 NFS - about 200K/s
SCO NFS - about 80K/s
FreeBSD NFS - about 12K/s
FreeBSD immediately writes every block it gets from DOS and reports about it
only after write is completed.
> 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.
Most of time Windows has only one active task with which the user works,
all other tasks are often just waiting until the user switches to them.
So the problem is the same as in DOS, although, obviously it is not so big.
> The easy answer is: don't use DOS, it sucks.
Yes :-( But the numbers above is one of reasons why people are using Netware,
not NFS.
> I think the issue was multple news reader processes and I/O being
> bottlenecked by requestst being queued for too few service engines.
OK, sorry... The low DOS+NFS performance is one of my problems and I ask
about it when I see something about NFS performance. :-)
Serge Babkin
! (babkin@hq.icb.chel.su)
! Headquarter of Joint Stock Commercial Bank "Chelindbank"
! Chelyabinsk, Russia
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511150359.IAA01506>