[nfsv4] Re: question around CB_GETATTR handling

[Trond Myklebust <[e-mail]>]

On Wed, 2024-09-04 at 12:23 -0400, Jeff Layton wrote:
> RFC 8881, section 10.4.3 has this pseudo code to describe how to
> handle
> the size and change attr:
> 
> ------------------8<-------------------
>     if (!modified) {
>         do CB_GETATTR for change and size;
> 
>         if (cc != sc)
>             modified = TRUE;
>     } else {
>         do CB_GETATTR for size;
>     }
> 
>     if (modified) {
>         sc = sc + 1;
>         time_modify = time_metadata = current_time;
>         update sc, time_modify, time_metadata into file's metadata;
>     }
> ------------------8<-------------------
> 
> 
> The line that shows sc = sc + 1 seems to indicate that we need to
> increment "sc" on every CB_GETATTR, even if nothing changed since the
> last time.
> 
> Is that correct or should we only increment it if it wasn't
> incremented
> before? The latter would make more sense, given that it doesn't query
> for change if the file is already considered to be modified.

I believe RFC5661 says

   For simplicity of implementation, the client MAY for each CB_GETATTR
   return the same value d.  This is true even if, between successive
   CB_GETATTR operations, the client again modifies the file's data or
   metadata in its cache.  The client can return the same value because
   the only requirement is that the client be able to indicate to the
   server that the client holds modified data.  Therefore, the value of
   d may always be c + 1.

Which is how the Linux client tries to implement it.
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[e-mail]