quoted

quoted

quoted

quoted

" " == Jan Harkes [off-list ref] writes:

     > It was? I really hope I wasn't one of the veto-ers because
     > looking at this problem it does seem like the correct thing to
     > do as we're not trying to see whether the path is correct, but
     > only the object.

Al was the main vetoer. His objection to i_op->revalidate() was that
it is interpreted differently for NFS, smbfs, coda,... For some it
just works like getattr(), for others it actually does an inode
revalidation...

     > 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?

     > btw. you can easily drop the lookup in nfs_lookup_revalidate.
     > It is a bug for this case, and not necessary in all other
     > places d_revalidate is called as the VFS already uses
     > real_lookup in those cases.

True, but that would be at the expense of increased dentry
aliasing.

Normally that is not a problem (and so we do tolerate it if operations
on the server are the cause), but under NFS we have to play tricks to
get around the problem of somebody doing 'unlink("file")' while we are
keeping the same file open for read()/write(). Basically we rename the
file to '.nfsxxxxx', and keep it until the last process to call
close() can do the actual unlink() rpc call to the server.
The resulting 'sillyrename()' feature (which is a recommended
implementation for all NFS clients) is intolerant of dentry/filename
aliasing.

Cheers,
  Trond