Re: Problems of lookup_revalidate

[David Chow <davidchow@shaolinmicro.com>]

Trond Myklebust wrote:

>On Monday 26 August 2002 17:53, David Chow wrote:
>  
>
>>Trond,
>>
>>I think the strategy used in 2.4.19 for NFS dentry and inode updates are
>>too weak. May be you have being pushing too hard on optimizing
>>performance (fewer lookups and revalidate). But I have problems that the
>>client d_cache() inconsistency. It seems when the server changes file
>>mode or ownership, the client is not updated properly unless I explicity
>>add a file in the parent directory at the server which triggers the
>>mtime of the parent, the client hardly update the dcache and inode
>>parameters properly. Please clarify if my guess is wrong. Thanks.
>>    
>>
>
>I don't see what you mean here. Attributes are indeed cached: see the 
>'actimeo' and 'noac' mount options. If you mess around with those attributes 
>on the server, and then call 'stat()' then you will indeed get wrong results. 
>So what?
>There is *no* guarantee that you can use to ensure that attributes are always 
>correct on the client. That's part of the protocol.
>
>Most (if not all) NFS clients therefore use attribute caching, and assume that 
>they only have to check the attributes when the cache times out *or* when 
>open() is called on the file.
>
>Cheers,
>  Trond
>  
>

Even I cat the file, the file seems still using the old cache on the 
client, but the server version has changed. Any possibilities? The mtime 
and size of the file at the server HAS changed so why not nfs client 
refresh_inode() on openning the file?

David