From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: [PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12) Date: Mon, 21 Oct 2002 13:07:01 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20021021170701.GA19844@ravel.coda.cs.cmu.edu> References: <20021017203804.GA24523@ravel.coda.cs.cmu.edu> <15791.12331.663212.692225@charged.uio.no> <20021017221652.GA26692@ravel.coda.cs.cmu.edu> <15791.20061.369962.893823@charged.uio.no> <20021018164916.GA11336@ravel.coda.cs.cmu.edu> <15792.16095.699839.453962@charged.uio.no> <20021018171211.GA12509@ravel.coda.cs.cmu.edu> <15792.18388.849961.869579@charged.uio.no> <20021018182352.GA13649@ravel.coda.cs.cmu.edu> <15792.24527.668600.662091@charged.uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: To: Trond Myklebust Content-Disposition: inline In-Reply-To: <15792.24527.668600.662091@charged.uio.no> List-Id: linux-fsdevel.vger.kernel.org On Fri, Oct 18, 2002 at 09:23:59PM +0200, Trond Myklebust wrote: > > Ok, it will cost Coda a whole upcall/context switch, but as it > > is '.' we're talking about it should already be locally > > cached. > > But if all you want to do is read the cache, you'd be better off with > d_revalidate(dentry,LOOKUP_DOT) / d_revalidate(dentry, LOOKUP_DOTDOT). > Wouldn't that allow you to drop the upcall+context switch too? Actually, as long as Coda hasn't received a callback from userspace indicating that the object has changed, it doesn't even make the getattr upcall. In fact I would probably end up with coda_dentry_revalidate calling coda_inode_revalidate in either of these cases. So why not just use iops->revalidate in the first place. As far as I can see, d_revalidate should just be used to check whether a cached directory path might have been changed (i.e. forces a real_lookup). While iops->revalidate checks the validity of the object. It also looks like 2.5 doesn't have this patch, so I'm assuming a change like this will be made to that tree at some point. And I'd rather see a variant that makes sense and doesn't change existing semantics, even when it might be less efficient for some filesystems. As long as it remains definitely correct. Especially the changed semantics of d_revalidate is what troubles me, - If I do the test on the object, I might 'reinstantiate' a possibly bad lookup path in the dcache because we revalidate the 'path' based on the object's state. - When I test the path, we return ESTALE whenever the path has changed due to rename, or on 'volatile objects' (Coda specific, mountpoints, objects under repair, etc.). So neither test ends up being correct. But if we use dentry_revalidate and inode_revalidate in the correct places it is immediately clear _what_ we're testing, the path leading up to the object or the object itself. Jan