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>