From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 20 15:15:27 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 4913B37B404; Fri, 20 Jun 2003 15:15:27 -0700 (PDT) Received: from frontend2.aha.ru (bird.zenon.net [213.189.198.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6B5243FF3; Fri, 20 Jun 2003 15:14:36 -0700 (PDT) (envelope-from uitm@blackflag.ru) Received: from [195.2.90.70] (HELO slt.oz) by frontend2.aha.ru (CommuniGate Pro SMTP 4.0.6) with ESMTP id 193251877; Sat, 21 Jun 2003 02:14:34 +0400 Received: (from uitm@localhost) by slt.oz (8.8.8/8.8.8) id CAA01809; Sat, 21 Jun 2003 02:16:22 +0400 (MSD) From: Andrey Alekseyev Message-Id: <200306202216.CAA01809@slt.oz> In-Reply-To: <200306202039.h5KKd5M7060679@gw.catspoiler.org> from Don Lewis at "Jun 20, 3 01:39:05 pm" To: truckman@FreeBSD.org (Don Lewis) Date: Sat, 21 Jun 2003 02:16:21 +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 22:15:27 -0000 Don, > old vnode and its associated file handle. If the file on the server was > renamed and not deleted, the server won't return ESTALE for the handle I'm all confused and messed up :) Actually, a rename on the server is not the same as sillyrename on the client. If you rename a file on the server for which there is a cached file handle on the client, next time the client will use its cached file handle, it'll get ESTALE from the server. I don't know how this happens, though. Until I dig more around all the rename paraphernalia, I won't know. If someone can clear this out, please do. It'll be much appreciated. At this time I can't link this with the inode generation number changes (as there is no new inode allocated when the file is renamed). I'm not strong in rename and sillyrename alchemy, just can deduce something from the code, though not much. However, I've just tested my patch with the rename-to-other-name-on-the-server scenario, and it seems to return ENOENT to the application after the local file pagecache is invalidated and the client tries to actually read the file from server using old name and old file handle. > Also, fixing open() doesn't fix similar problems that can occur with > other syscalls that take path names, such as stat() and readlink(). That's a good point. However, if the patch for open() succeeds it can be further extended to other syscalls as well. > If the lookup code is changed so that it more frequently revalidates the > name->vnode->handle entries, then the window where open() can fail due > to ESTALE would be greatly reduced. Sorry, I've got no time for that :) I'm generally not in this area of activities. At least for the next few years I'm an extremely busy man :) Again, thanks a lot for your comments.