Date: Thu, 9 Oct 1997 13:00:27 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Karl Denninger <karl@mcs.net> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Robin Cutshaw <robin@intercore.com>, freebsd-current@freebsd.org Subject: Re: NFS cache problem in 3.0 SNAP Message-ID: <199710091900.NAA16536@rocky.mt.sri.com> In-Reply-To: <19971009132146.18909@Mars.Mcs.Net> References: <19971009120208.12168@Mars.Mcs.Net> <2907.876419943@critter.freebsd.dk> <19971009132146.18909@Mars.Mcs.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710091900.NAA16536>