From owner-freebsd-current Thu Oct 15 15:58:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23185 for freebsd-current-outgoing; Thu, 15 Oct 1998 15:58:27 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23174 for ; Thu, 15 Oct 1998 15:58:25 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id RAA20521; Thu, 15 Oct 1998 17:56:58 -0500 (CDT) From: Kevin Day Message-Id: <199810152256.RAA20521@home.dragondata.com> Subject: Re: -current NFS problem In-Reply-To: <199810152244.PAA22563@usr04.primenet.com> from Terry Lambert at "Oct 15, 98 10:44:17 pm" To: tlambert@primenet.com (Terry Lambert) Date: Thu, 15 Oct 1998 17:56:57 -0500 (CDT) Cc: dg@root.com, green@zone.syracuse.NET, grog@lemis.com, julian@whistle.com, mike@smith.net.au, bag@sinbin.demos.su, rock@cs.uni-sb.de, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >Well, according to Jordan's "non-verification" to my alluding that since > > >Dr. McKusick was committing NFS deltas, he was the mysterious contracted > > >NFS fixer-upper. Last time I checked, he didn't really do his entire job > > >if that was to totally fix NFS.... but hey, I don't use NFS much if ever, > > >so I won't Complain... > > > > Kirk was contracted to fix the problems that he could fix in a short amount > > of time. He did that and confirmed my own analysis of the remaining problems, > > which basically all stem from lack of FS node locking in the NFS code. Adding > > such locking opens a very large can of worms and everyone who has tried to > > do this has failed. > > Not everyone. Network Appliance, Sun Microsystems, USL, and SCO > have all got working NFS. I think BSDI has working NFS as well, > including locking based one some of the stub code produced for > FreeBSD by Andrew (and by me), and I'm pretty sure the NFS code, > sans locking, worked before it left the University of Guelph. > > The problems with NFS in FreeBSD are architectural problems with > FreeBSD. Until someone starts committing fixes for the architectural > problems, you're going to continue to see their effects percolate > up to the surface in various places (like the recent complaints > by someone trying to do advisory locking on sockets; an fd is an > fd, right? Wrong). > > To put it another way, if the foundation is out of square, then > any house you build on the foundation will also be out of square. > > I would like to recommend contacting John Heidemann about the > differences between his stacking vnode VFS architecture and the > implementation of that architecture in FreeBSD. At least it > would be a starting point for addressing some of these things, > with an appeal to an authority everyone can respect instead of > a disagreement between peers. > I don't think it's just architectural problems that people are complaining over though. I'd be perfectly happy to go back to 3.0 if nfs didn't cause kernel panic's. I can deal with the limitations that freebsd's implementation has, as long as one of those limitations isn't "Don't expect a >24 hour uptime, if you're making heavy use of NFS." 2.2 is stablish when it comes to NFS. I get randomly corrupted files, but it's so rare, i don't worry much about it. 3.0 causes kernel panics up the wazoo. (nfsbioread, Bad nfs svc reply, nfs rcvunlock, bwrite: buffer is not busy???, etc..... page fault while in kernel mode comes up often, too) That's my only present beef when it comes to NFS. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message