*BSD News Article 34150


Return to BSD News archive

Xref: sserve comp.os.386bsd.questions:12257 comp.os.386bsd.misc:3144
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!cs.utexas.edu!convex!news.duke.edu!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!trib.apple.com!amd!netcomsv!calcite!vjs
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: Whats wrong with Linux networking ???
Message-ID: <CuDJox.HE2@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Thu, 11 Aug 1994 14:17:20 GMT
References: <327nj0$sfq@sundog.tiac.net> <328fn2$i9p@news.panix.com> <32bflj$lig@cesdis1.gsfc.nasa.gov>
Lines: 36

In article <32bflj$lig@cesdis1.gsfc.nasa.gov> becker@cesdis.gsfc.nasa.gov (Donald Becker) writes:

> ...
>The NFS protocol assures the client that when the write-RPC returns, the
>data block has been committed to persistent storage.  For common
>implementations that means the block has been physically queued for writing,
>not just put in the buffer cache. ...

An NFS server that only queues the block for writing before responding
instead of waiting for the disk controller to say that the write has
been completed does not meet the NFS "stable storage" rules.  Such a
server would suffer the slings, arrows, and sneers of those who do not
believe in async. NFS servers, including not being able to report LADDIS
numbers, but would fail to gain much of the benefit of async writes.

(Note that I qualify as one of the Great Satan advocates of async NFS
writes.  The commercial implemenation I'm currently associated is shipped
with async writes on by default.)


>                          ...   You can get around this by writing a client
>implementation that allows multiple outstanding write requests for each
>writing thread, at the expense of write order inconsistency.
> ...

The client implementations I know about permit multiple outstanding
write requests for each application thread, although not for the kernel
threads that are flushing the client buffer cache.  (Assuming the
application thread did not ask for sync writes).  None that I know of
gain any useful write order consistency.  Write order consistency strikes
me as a odd consideration for an NFS client, given that one cannot know
about the NFS requests of other clients and given the chaos caused by
retransmissions.


Vernon Schryver    vjs@rhyolite.com