From owner-freebsd-current Thu Oct 9 15:27:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04336 for current-outgoing; Thu, 9 Oct 1997 15:27:42 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA04324 for ; Thu, 9 Oct 1997 15:27:37 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id RAA24855; Thu, 9 Oct 1997 17:25:55 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id RAA05351; Thu, 9 Oct 1997 17:25:54 -0500 (CDT) Message-ID: <19971009172554.38660@Mars.Mcs.Net> Date: Thu, 9 Oct 1997 17:25:54 -0500 From: Karl Denninger To: Karl Denninger Cc: Poul-Henning Kamp , Robin Cutshaw , freebsd-current@FreeBSD.ORG Subject: Re: NFS cache problem in 3.0 SNAP References: <19971009132146.18909@Mars.Mcs.Net> <2997.876422674@critter.freebsd.dk> <19971009135128.24005@Mars.Mcs.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <19971009135128.24005@Mars.Mcs.Net>; from Karl Denninger on Thu, Oct 09, 1997 at 01:51:28PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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