From owner-freebsd-hackers Sun Aug 20 22:41:46 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA23239 for hackers-outgoing; Sun, 20 Aug 1995 22:41:46 -0700 Received: from simon.chi.il.us (simon.chi.il.us [199.245.227.17]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id WAA23223 for ; Sun, 20 Aug 1995 22:41:41 -0700 Received: by simon.chi.il.us (Smail3.1.29.1 #3) id m0skPcC-0006IIC; Mon, 21 Aug 95 00:41 CDT Message-Id: Date: Mon, 21 Aug 95 00:41 CDT From: steve@simon.chi.il.us (Steven E. Piette) To: terry@cs.weber.edu Subject: Re: Making a FreeBSD NFS server Cc: freebsd-hackers@freebsd.org Sender: hackers-owner@freebsd.org Precedence: bulk > 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.