From owner-freebsd-hackers Sun Aug 20 13:56:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA18118 for hackers-outgoing; Sun, 20 Aug 1995 13:56:25 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id NAA18112 for ; Sun, 20 Aug 1995 13:56:24 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA23361; Sun, 20 Aug 95 14:56:33 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508202056.AA23361@cs.weber.edu> 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 Cc: taob@gate.sinica.edu.tw, freebsd-hackers@freebsd.org In-Reply-To: from "Steven E. Piette" at Aug 20, 95 12:33:00 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > > 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. 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'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-). Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.