From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 20 00:16:36 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 8D1CB37B401; Fri, 20 Jun 2003 00:16:36 -0700 (PDT) Received: from frontend3.aha.ru (elk.zenon.net [213.189.198.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CC3243F75; Fri, 20 Jun 2003 00:16:35 -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 7962419; Fri, 20 Jun 2003 11:16:33 +0400 Received: (from uitm@localhost) by slt.oz (8.8.8/8.8.8) id LAA00471; Fri, 20 Jun 2003 11:18:26 +0400 (MSD) From: Andrey Alekseyev Message-Id: <200306200718.LAA00471@slt.oz> In-Reply-To: <200306200617.h5K6HaM7058935@gw.catspoiler.org> from Don Lewis at "Jun 19, 3 11:17:36 pm" To: truckman@FreeBSD.org (Don Lewis) Date: Fri, 20 Jun 2003 11:18:24 +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:16:36 -0000 Don, > I can't get very enthusiastic about changing the file system independent > code to fix a deficiency in the NFS implementation. You're right. But it appears to be hard and inefficient to fix NFS for this (I tried, though). It will certainly require to pass names below VFS. On the other hand, there are NFS-related functions in the VFS already. See vfs_syscalls.c:getfh(), fhopen() and similar functions. There are things related to NFS server in the UFS/FFS code too. So, I finally decided that my "fix" doesn't do much harm to the above mentioned concept :) > current working directory, and your current working directory is nuked > on the server, vn_open will return ESTALE, and your patch above will > loop forever. It won't loop forever :) The "stale" integer is in there exactly for that purpose :) In case of a stale current directory, open() will still return ESTALE. In case of a file that was rm'd from the server, I believe it'll return something different. > If the rename on the server was done within the attribute validity time > on the client, vn_open() will succeed even without your patch, but you > may encounter the ESTALE error when you actually try to read or write > the file. Sure! But open() will succeed and probably you'll even be lucky to get file contents from the cache. But that's another story, related to attributes tuning (I have another patch for that:) However, even with the existing FreeBSD NFS attribute cache behaviour, it's ok for me. > server could do the rename while the client has the file open, after > which some I/O operation on the client will encounter ESTALE. Sure. That's perfectly understood. I'm not trying to solve all the NFS inefficiencies related to heavily shared files. > acdirmin/acdirmax, or a new handle timeout parameter. This may decrease > performance, but nothing is free ... In the normal situation, namecache entry+vnode+nfsnode+file handle may stay cached for a really long time (until re-used? deleted or renamed on the *client*). Expiring file handles (a new mechanism?) means much the same to me as simply obtaining a new name cache entry+other data on ESTALE :) I may be wrong, though. Anyway, thanks for the comments. See also: http://www.blackflag.ru/patches/nfs_attr.txt