From owner-freebsd-current Tue Mar 5 10:32:24 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA13586 for current-outgoing; Tue, 5 Mar 1996 10:32:24 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA13578 for ; Tue, 5 Mar 1996 10:32:18 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08730; Tue, 5 Mar 1996 11:29:18 -0700 From: Terry Lambert Message-Id: <199603051829.LAA08730@phaeton.artisoft.com> Subject: Re: Does NFS Version 3 stuff work? To: brian@easy1.mediacity.com (Brian Litzinger) Date: Tue, 5 Mar 1996 11:29:18 -0700 (MST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <199603050341.TAA14005@MediaCity.com> from "Brian Litzinger" at Mar 4, 96 07:41:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > Does the NFS Version 3 stuff work in -current? In my opinion: yes, with the caveat that you should not be using leases. The lease problem is, I think, related to the cache issue re: vnodes without associated inodes having their cache data flushed. Under heavy load, I believe leases would fail to do their job... in particular, a high vnode recycle rate (such as from a "find" on one or more clients) could cause a large race window. See the "xfs" discussion for more details. Obviously, I'd prefer the use of my FS patches as a whole, but there *are* some NFS related patches that eliminate at least two races that I know about combined with the nameifree reordering changes in the code where I caused a forced seperation of the FS interface abstraction from the underlying FS code. Finally, there are some known issues with the cookie code; the -hackers list archive of a discussion between myself and Doug Rabson on directory iteration restart without use of the "cookie" mechanism is applicable, if you want to work on resolving that. The cookie code is one of the big differences between FreeBSD and NetBSD implementations to get around the NFS wire vs. UFS storage encoding differences for the directory entry iteration interface used by the POSIX opendir/readdir/seekdir/telldir/closedir interface. The cookie issues are unrelated to the V3 code itself (except as it uses the cookies blindly, but they are opaque at that level), and the race conditions are issues with the underlying FS that NFS is calling to export file systems (and that's more a problem in the mount code and te recent "rename" race problems). If you have a problem finding any of the information, let me know; it will take me a while to get back to you on any request that large, but I could, eventually. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.