Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Aug 95 00:41 CDT
From:      steve@simon.chi.il.us (Steven E. Piette)
To:        terry@cs.weber.edu
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Making a FreeBSD NFS server
Message-ID:  <m0skPcC-0006IIC@simon.chi.il.us>

next in thread | raw e-mail | index | archive | help

> From: terry@cs.weber.edu (Terry Lambert)
> Subject: Re: Making a FreeBSD NFS server
> To: steve@simon.chi.il.us (Steven E. Piette)
> Date: Sun, 20 Aug 95 14:56:32 MDT
> 
> > > The SGI, being SVR4 based, is doing async writes on the server by
> > > default.  The BSD box is waiting for the write to be comitted to
> > > the server disk before continuing.
> > > 
> > > You can turn on async writes in the BSD NFS server.
> > > 
> > > Be warned that, though Sun and SVR4 do this too, this is a cache
> > > coherency violation and can result in Bad Things Happening in case
> > > of a server power failure or other failure that results in the
> > > server going down, then coming back up while the app on a client
> > > is still running.  This is because the client will think the data
> > > was written and may depend on being able to retrieve it later
> > > (ie: a database index).
> > 
> > Terry, Do you bother checking your references before you make blanket
> > statements or do you like to just wing it? Do you bother checking them
> > after someone points out your errors?
> 
> Well, I know the SGI does async writes, and does them by default.
> 
> I know that SVR4, at least the UnixWare release, which is really the
> only release there is any more, does async writes -- I was in one of
> the meetings that decided to do it while I was arguing for optioning
> it with it "off" by default.  I lost.  The benchmark optimizers won.
> 
> So the above is a correct blanket statement.

As I said earler, This mail wasn't suppost to be sent. My mistake. I'm
sorry. What I was really responding to was a interpretation on my part that
you were saying, that Sun's do async writes by default, and what you just
did say, that SVR4 (in the generic case) does as well. As others have
pointed out Sun does sync writes by default and belives some sort of
NVRAM is required to support safe async writes in NFS today.

I had put my response aside to refer to both the SVID and the pre V3 NFS spec
before commenting and I sure I would have revised my initial response
which is more akin to talking to myself that actually directed at you.

I've since checked SVID 3 and it says nothing about the expected behaviour
of NFS writes, so I say that in SVR4 its an implementation detail. I haven't
today checked the V2 NFS spec as to what it says about async writes, so I
won't comment further on conformance. 

> 
> I *did* check the cache coherency claims about NFSv3.  And given the
> exact wording of the RFC (which does not match the Sun White Paper
> of two years ago), safe async writes are guaranteed, but full cache
> coherency is not.

I hadn't gotten that far in your message...

> 
> I'd like to think that the directory search/stat combination and
> multiple entry transfers came out of some of the attributed file
> system work we demonstrated for Sun about a year before the Sun
> NFSv3 paper came out.  It's more likely that we just arrived at a
> similar soloution to similar problems, but as a result, I spent
> an inordinate amount of time going over the Sun paper.
> 
> For the purposes of the discussion, cache coherency amounted to async
> writes being safe, not to dealing correctly with memory mapped files
> over NFS.  It was not my intent to draw that fine a distinction, and
> so I was wrong on a technicality.
> 
> That was an omission on my part, and I've already owned up to it, though
> not in this great gory detail.
> 
> What is your point?  That I don't take the same pains to research
> email and dot all the "i"'s and cross all the "t"'s, as long as I
> get the gist across, that I would take were I writing a book?  I'll
> freely admit that... probably I'll keep doing it until someone pays
> me book rates to do posting.  8-).

Think by now you understand I had no point. :-) I was thinking with my
fingers and before I'd done what I accused you of, it got sent out with a
bunch of other messages I was sending. I even shut down my link and deleted
the message from the queue when I realized what that happened but I didn't
kill the smail process that was still active trying to deliver the message.

The result was that I snapped at you. And for that I apologize.

> 
> 
> 
> 					Regards,
> 					Terry Lambert
> 					terry@cs.weber.edu


Steve

I got to start drinking more coffee in the mornings before I start reading mail.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0skPcC-0006IIC>