From owner-freebsd-current Thu Oct 9 12:04:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21244 for current-outgoing; Thu, 9 Oct 1997 12:04:17 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA21230 for ; Thu, 9 Oct 1997 12:04:03 -0700 (PDT) (envelope-from nate@rocky.mt.sri.com) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id NAA12118; Thu, 9 Oct 1997 13:00:27 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id NAA16536; Thu, 9 Oct 1997 13:00:27 -0600 (MDT) Date: Thu, 9 Oct 1997 13:00:27 -0600 (MDT) Message-Id: <199710091900.NAA16536@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Karl Denninger Cc: Poul-Henning Kamp , Robin Cutshaw , freebsd-current@freebsd.org Subject: Re: NFS cache problem in 3.0 SNAP In-Reply-To: <19971009132146.18909@Mars.Mcs.Net> References: <19971009120208.12168@Mars.Mcs.Net> <2907.876419943@critter.freebsd.dk> <19971009132146.18909@Mars.Mcs.Net> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The problem we see here which is very repeatable is this: > > Boxes (1 and 2, server is on system 3 which is not involved) > > 1: mv file1 file2 > 2: cat file1 (still works) > 1: cp file3 file1 > 2: cat file1 (still shows OLD contents of file 1) > 1: rm file1 > 2: cat file1 (STILL shows old contents - you've now lost the ability > to get at the handle which was there first!) > > This is bad. I can do this, albeit inconsistantly on my Solaris boxes here (both running Solaris 2.5, soon to be 2.6). Both machines have their clocks sync'd to my local NTP server, so it's not a time-stamp problem. > Here's another: > 1: rm file1 > 2: cat file1 (returns "Stale NFS handle" - not file not found!) > 1: cp file3 file1 > 2: cat file1 (now shows proper content; it "fixed itself") This seems to be correct behavior, is it not? (Other than the Stale NFS handle.) This also seems to happen fairly regularly on the Solaris boxes doing such things. Nate ps. The reason I mention this is because Solaris is what I consider to be the 'standard' for NFS, and if they can't even get it right.