From owner-freebsd-hackers Thu Jan 11 13:12:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA20038 for hackers-outgoing; Thu, 11 Jan 1996 13:12:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA20014 for ; Thu, 11 Jan 1996 13:11:59 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18176; Thu, 11 Jan 1996 14:07:08 -0700 From: Terry Lambert Message-Id: <199601112107.OAA18176@phaeton.artisoft.com> Subject: Re: Stale NFS file handle To: jhay@mikom.csir.co.za (John Hay) Date: Thu, 11 Jan 1996 14:07:07 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199601112024.WAA28370@zibbi.mikom.csir.co.za> from "John Hay" at Jan 11, 96 10:24:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Can you provide a way of repeating the problem in situ? > > > > Will it work against non-FreeBSD servers or with non-FreeBSD clients? > > (ie: have you localized the problem to the server or client code?). > > > > Is it possible the the handle is, in fact, stale? > > > > What if you disable the lease code (assuming NFSv3)? > > This is with FreeBSD-2.1 as client and a Netware (NFS) server. I believe the > handle is stale (They changed disks without telling us beforehand), but I > cannot get it unmounted, not even with umount -f which I would have thought > should force it. At the moment it looks like I will have to reboot the > FreeBSD machines to clear the problem. > > The HP machines which also mounted the Netware server, could unmount > it with the force option. Ah. The force option in the FreeBSD NFS isn't. Probably, you have dirty data buffers associated with the BSD vnodes and that's what's killing you. A stale handle happens when the cookie lookup on the server causes a mismatch on the generation count for the file (NetWare preincrements) or in the UNIX server case, a generation count mismatch or a zero reference count. Eventually, someone needs to fix the force to make it actually work, but really the whole mount/unmount API wants a change so that this isn't a problem anyway. If the stale handle data were discarded when the handle was determined to be stale (logical, since the client can't force the write), then it should resolve the problem. Probably you were writing at the instant when the server blew chunks. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.