Problems of lookup_revalidate

Problems of lookup_revalidate

[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.

David

Re: Problems of lookup_revalidate

[Trond Myklebust]

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

Re: Problems of lookup_revalidate

[David Chow]

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

Re: Problems of lookup_revalidate

[Trond Myklebust]

>>>>> " " == David Chow <davidchow@shaolinmicro.com> 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

Re: Problems of lookup_revalidate

[David Chow]

Trond Myklebust wrote:

>>>>>>" " == David Chow <davidchow@shaolinmicro.com> 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
>  
>
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

Re: Problems of lookup_revalidate

[Trond Myklebust]

On Thursday 29 August 2002 11:26, David Chow wrote:

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

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

Re: Problems of lookup_revalidate

[Trond Myklebust]

On Thursday 29 August 2002 11:26, David Chow wrote:

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

Re: Problems of lookup_revalidate

[Bryan Henderson]

>2.4.18 does not support close-to-open.

Can you elaborate?  Are you saying that in 2.4.18 if I write to a file and
close it and then someone opens that file, he won't necessarily see the
data and metadata updates I made?

Is this a property of the 2.4.18 NFS client or 2.4.18 NFS server?

Re: Problems of lookup_revalidate

[Trond Myklebust]

>>>>> " " == Bryan Henderson <hbryan@us.ibm.com> writes:

    >> 2.4.18 does not support close-to-open.

     > Can you elaborate?  Are you saying that in 2.4.18 if I write to
     > a file and close it and then someone opens that file, he won't
     > necessarily see the data and metadata updates I made?

That's correct. Some people have ben trying to work around this by
using the 'noac' mount option. That helps, but is serious overkill...

     > Is this a property of the 2.4.18 NFS client or 2.4.18 NFS
     > server?


It's a limitation of the 2.4.18 client.

Cheers,
  Trond