Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Oct 1997 17:25:54 -0500
From:      Karl Denninger  <karl@Mcs.Net>
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:  <19971009172554.38660@Mars.Mcs.Net>
In-Reply-To: <19971009135128.24005@Mars.Mcs.Net>; from Karl Denninger on Thu, Oct 09, 1997 at 01:51:28PM -0500
References:  <19971009132146.18909@Mars.Mcs.Net> <2997.876422674@critter.freebsd.dk> <19971009135128.24005@Mars.Mcs.Net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 09, 1997 at 01:51:28PM -0500, Karl Denninger wrote:
> On Thu, Oct 09, 1997 at 08:44:34PM +0200, Poul-Henning Kamp wrote:
> > In message <19971009132146.18909@Mars.Mcs.Net>, Karl Denninger writes:
> > >On Thu, Oct 09, 1997 at 07:59:03PM +0200, Poul-Henning Kamp wrote:
> > >> 
> > >> I backed my VOP_LOOKUP change out recently, I pressume that improved
> > >> the situation a bit or hur ?
> > >
> > >Uh, when?  I just looked through the commitlogs for sys and didn't see it....
> > 
> > 1.62
> > date    97.10.05.12.28.59;      author phk;     state Exp;
> > 
> > Reverse rev 1.56 and rev 1.59.  These made NFS too flakey.
> > 
> > 
> > --
> > Poul-Henning Kamp             FreeBSD coreteam member
> > phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> 
> Hmmm... how did I miss that one? :-)
> 
> I'll get 1.41 of nfs_bio out again (the current rev causes panics) and
> retest.

It's "better", but still not right (well, ok, as right as you can be).

Now the symptom is that a "mv" works, *but* the old file will not
necessarily be removed from the cache on the second system in its old
location.

To reproduce:

	Web server with log files on an NFS volume.  Server is running.
	"mv" the logfiles to another location on the same volume (ie: an
		"OLD" directory under the logdir)
	"kill -1 server-pid" on the server.
		This *should* cause NCSA's server (and most others) to close 
		and re-open the log files, which *should* cause the files
		to "reappear" in the original location and the old copies to
		be closed.  However, that doesn't happen -- the originals,
		although visible in the OLD directory now (and not in the
		original place) are still being written to even though
		they were closed and re-opened on System #2.  This used
		to work prior to about mid-September.

	"kill server-pid" to completely shut the server down.
	Wait a minute or so.
	Restart the server.

		NOW the log files are re-created in the right place.

	It appears that if the cached inode doesn't age off before the file
	is re-opened, then I/O will not be performed (ie: the client doesn't
	"notice" that the file was modified).

This is liveable; at least you don't get the stale file handles and files
which disappear out from under you (and which are also unrecoverable).

--
-- 
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | NEW! K56Flex modem support is now available
Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines!
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971009172554.38660>