On Mon, May 23, 2011 at 1:47 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 23 May 2011 13:24:41 -0500 > Steve French <smfrench@xxxxxxxxx> wrote: > >> On Mon, May 23, 2011 at 1:23 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >> > On Mon, May 23, 2011 at 01:21:35PM -0500, Steve French wrote: >> >> Until Peter's Linux NFS fix is in - aren't we in that situation >> >> already with other fs. >> > >> > That patch is not going to help with the fundamental problem that >> > you won't be able to ever find an inode that went out of cache. >> >> Isn't that what Peter's fix (and Solaris and other clients do) - they >> revalidate the inode via another nfs lookup when it has gone stale. >> > > Only if the client actually has a valid path to work with. That's not > guaranteed. Even if it were, pushing responsibility for this out to the > client totally violates the protocol. > > It's the server's job to be able to identify filehandles that the > client presents. It should not have to rely on the client to look up > the right path to ensure that it's in its cache. > > Even if the client were to do that, it's not 100% certain that it will > still be in the cache after the LOOKUP call and before the call that > wants to use a filehandle. If the server is under serious memory > pressure it could get pushed out of the cache again within that window. If the file is open the dentry will be in cache... right? In any case, Linux has been doing this for many years with FAT. See fat_fh_to_dentry (in fs/fat/inode.c) it calls ilookup on the fh - if it isn't in cache it calls d_obtain_alias with null which causes ESTALE to go back from nfsd to the nfs client. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
