Re: [nfsv4] handling GETATTR vs. fh with outstanding write delegation

On Thu, May 25, 2023, 6:38 PM Jeff Layton <jlayton@kernel.org> wrote:

> On Thu, 2023-05-25 at 13:45 +0000, Chuck Lever III wrote:
> >
> > > On May 25, 2023, at 7:46 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > >
> > > Dai has started (finally) implementing write delegations in the Linux
> > > kernel NFS server, and we've been looking to the spec for guidance.
> > > This section of RFC8881 has a long treatment on the use of CB_GETATTR:
> > >
> > >    https://datatracker.ietf.org/doc/html/rfc8881#section-10.4.3
> > >
> > > At the bottom, in particular, it says:
> > >
> > >    It should be noted that the server is under no obligation to use
> > >    CB_GETATTR, and therefore the server MAY simply recall the
> > >    delegation to avoid its use.
> > >
> > > However, at least one server implementor (Netapp) seems to ignore this.
>

As Chuck pointed out,  the filer is not ignoring this statement, although
it is
Not following a related part of the spec.

>
> > "Ignore" is a strong word. IMHO other implementers interpret this
> > compliance statement perhaps differently than you did.
> >
> >
>
> Maybe. It sounds to me however like the RFC is saying you have 2 choices
> when satisfying a GETATTR for size/change_attr:
>

I  think that is what the spec does say.

>
>    1/ CB_GETATTR
>
> ...or...
>
>    2/ recall the delegation
>
> If that wasn't intended and there is a 3rd way, then it would be nice to
> clarify that.
>

I think that it *was* intended.  If you think there is a third way, you
should submit an errata report, we can discuss the issue and address this
in rfc5661bis.

>
> > > The filer simply reports the info it has in response to a GETATTR
> > > without using CB_GETATTR and without recalling a delegation.
> >
> > As a data point, the Solaris server implementation also does not
> > implement CB_GETATTR, nor does it send a CB_RECALL in this case.
> >
>
> Good to know, thanks.
>

So we have two servers that behave this way.  From the tone of your
previous message, we may have a third under development.  Also, it would be
nice to know of any servers that do follow rfc8881 in this regard.

>
> >
> > > Given that the client can buffer up writes even when it doesn't have a
> > > write delegation, what's the rationale for requiring a tighter level of
> > > cache coherency just because there is a delegation outstanding?
> > >

I think the rationale behind this is the nature of the delegation, which
transfers the server's normal rights to change the file to the client
holding the delegation.  As  a result, lots of things that are doable by
other clients in the absence of a delegation cause a recall in its
presence.  If the working group decides that is too stringent, it could
make this a "SHOULD" but I'm still not sure we want to take this step.

>
> > > Note that we have not yet implemented timestamp/attr delegations:
> > >
> > >    https://datatracker.ietf.org/doc/draft-ietf-nfsv4-delstid/02/
> > >
> > > Will we be any worse off if we were to also ignore this bit of the spec
> > > and allow GETATTRs without CB_GETATTR or CB_RECALL?
>

Given that neither Solaris or Ontap has had any difficulties from their
non-compliance, you probably would be OK unless something new turns up.

> --
> Jeff Layton <jlayton@kernel.org>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>