From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 20 00:03:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D91137B401 for ; Fri, 20 Jun 2003 00:03:52 -0700 (PDT) Received: from frontend3.aha.ru (elk.zenon.net [213.189.198.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6129843F93 for ; Fri, 20 Jun 2003 00:03:50 -0700 (PDT) (envelope-from uitm@blackflag.ru) Received: from [195.2.90.70] (HELO slt.oz) by frontend3.aha.ru (CommuniGate Pro SMTP 4.0.6) with ESMTP id 7959220; Fri, 20 Jun 2003 11:03:48 +0400 Received: (from uitm@localhost) by slt.oz (8.8.8/8.8.8) id LAA00432; Fri, 20 Jun 2003 11:05:29 +0400 (MSD) From: Andrey Alekseyev Message-Id: <200306200705.LAA00432@slt.oz> In-Reply-To: <3EF29A62.5E91D714@mindspring.com> from Terry Lambert at "Jun 19, 3 10:23:46 pm" To: tlambert2@mindspring.com (Terry Lambert) Date: Fri, 20 Jun 2003 11:05:28 +0400 (MSD) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: open() and ESTALE error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 07:03:52 -0000 Terry, Thanks much for you comments, but see below. > The real problem here is that you know you did an operation > on the file which would break the name/nfsnode relationship, > but did not flush the cached name and nfsnode data. nfs_request() actually calls cache_purge() on ESTALE, and vn_open() frees vnode with vput() if a lookup was successful but there were an error from the underlying filesystem (like ESTALE resulting from nfs_request() which is eventually called from VOP_ACCESS or VOP_OPEN). > A more correct solution would resync the nfsnode. I think this is exactly what happens :) Actually, I believe, I'm just getting another namecache entry with another vnode/nfsnode/file handle. > The main problem with your solution is that it doesn't work > in the case that you don't know the name of the remote file > (in which case, all you really have is a stale file handle, > with no way to unstale it). I think, in this case (if the file was rm'd on the server), I'll just get ENOENT from the second vn_open() attempt, which would be more than appropriate. A real drawback is that for a stale "current" directory it'll take another lookup to detect "true" ESTALE. > This would fix a lot more cases than the single failure you > are fixing. Actually, as I said, I played with different parts of the code to solve this (including, nfs_open(), nfs_access(), nfs_lookup() and vn_open()) only to find the previously mentioned solution to be the simpliest and most suitable for all situations (for me!) :)