Problems of lookup_revalidate
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.
David
Quoted 10 lines · David Chow
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
Quoted 16 lines · Trond Myklebust
Quoted 12 lines · David Chow
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.
Quoted 9 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == David Chow <[email protected]> writes:
> 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?
That should normally not happen. Are you also updating ctime properly on the server when you change the mtime/size?
Cheers,
Trond
Quoted 10 lines · Trond Myklebust
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
" " == David Chow <[email protected]> writes:
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?
Quoted 7 lines
That should normally not happen. Are you also updating ctime properly on the server when you change the mtime/size?
Cheers,
Trond
Of course the ctime has changed because the file is edited and saved at the server. The problem is it is not close-to-open in this case. I notice dir.c has some change in lookup_revalidate(), whats the purpose of the change from 2.4.18 to 2.4.19? I have no problem in 2.4.18 .
David
Quoted 5 lines · David Chow
Of course the ctime has changed because the file is edited and saved at the server. The problem is it is not close-to-open in this case. I notice
dir.chas some change inlookup_revalidate(), whats the purpose of the change from 2.4.18 to 2.4.19? I have no problem in 2.4.18 .
2.4.18 does not support close-to-open. The changes introduced in 2.4.19 are supposed to ensure that close-to-open is observed.
Cheers,
Trond
Quoted 5 lines · David Chow
Quoted 5 lines
Quoted 5 lines
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?
Could you send me the syslog output after doing
echo "1" >/proc/sys/sunrpc/nfs_debug
and then reproducing the problem?
Cheers,
Trond