> > Also, AFAICS the non-cached lookup might be necessary so that
> > we'd ignore any negative cache entry we might have, so that
> > following steps would really remove the file:
> > 
> > 1. do local lookup (ls 'file')
> > 2. some other client creates 'file'
> > 3. rm 'file'
> > 
> > Though NFS code might actually check if the entry returned
> > by cache_lookup() is still valid, so the negative cache entry
> > would be ignored nevertheless.
> 
> We'd need to change the nami cache interface some for this. AFAICT 
> cache_lookup() doesn't actually return the cache entry, it just returns 
> ENOENT. To do what you're suggesting (which I think is good), we'd need to 
> add a way for a file system to hang data off of the cache entry, so that 
> nfs can time out the entry.
> 
> As a simpler step, we could just adjust cache_lookup() so that it only 
> uses the negative cache entry for LOOKUPs, not != CREATE. As long as 
> rename and delete ops have MAKEENTRY off and we remove the entry if 
> MAKEENTRY isn't there, we never hit this code path, so the two conditions 
> (== LOOKUP, != CREATE) are the same.

nfs code already checks validity of negative caches by
checking the directory's ctime.  do you mean it isn't enough?

YAMAMOTO Takashi