Re: NFSv4.2 server replies to Copy with length == 0

> -----Original Message-----
> From: Daniel Gryniewicz [mailto:[email protected]]
> Sent: Monday, October 21, 2019 8:44 AM
> To: Rick Macklem <[email protected]>; Frank Filz
> <[email protected]>; 'Tom Talpey' <[email protected]>; [email protected]
> Subject: Re: [nfsv4] NFSv4.2 server replies to Copy with length == 0
> 
> On 10/21/19 10:24 AM, Rick Macklem wrote:
> > Frank Filz wrote:
> >>> (That's why I've asked other implementors to put their hands up and,
> > sofar,
> >>> there hasn't been any hands up. I thought Ganesha was working on
> >>> NFSv4.2,
> > but
> >>> no one has posted on [email protected] about it.)
> >>
> >> Sorry no one from Ganesha has raised their hand. I have been watching
> >> this discussion, but we have limited 4.2 support. As far as I know,
> >> no one has implemented server side copy on Ganesha.
> > Along with the Copy ones, there is the problem I brought up a while
> > ago w.r.t Seek. I recall Ganesha did encounter that one?
> > The case is:
> > Seek
> > Arguments:
> > sa_offset:  <file_size>
> > sa_what:     NFS4_CONTENT_DATA
> >
> > Reply that Linux client expects:
> > (A) NFS4ERR_INVAL
> > whereas the RFC seems to indicate
> > (B) NFS_OK
> >        sr_eof: true
> >        sr_offset: <file_size>
> >
> > Which of these does you current code implement?
> > (If it is (B), the code I posted will break when run on a Linux client
> >   against your server.)
> 
> We currently return NFS4ERR_NXIO for >= <file_size>.  Reading the spec, this
> should probably only be > <files_size>.  We don't explicitly deal with DATA at the
> end, it's currently delegated to the clustered filesystem implementation, so I
> don't know what we'd return if we fixed this check.  So we currently to neither
> of those two things.

Yea, we return A in this case so we confirm to the Linux client rather than the spec.

> >
> > Has this code shipped to users yet?
> 
> Yes.  However, the downstreams don't support it yet.  We have a history of
> changing our behavior to be spec compliant, anyway, so we're happy to change.

Yea, we would be happy to follow the spec if the Linux client also changes. Changing to follow the spec and breaking the Linux client doesn't seem wise at this point.

Frank

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4