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

Daniel Gryniewicz wrote:
>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
    Oops, it should be NFS4ERR_NXIO here.
>> 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.
>
Yes, this is the Linux way.

>>
>> 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.
If you change it to be spec. compliant, then interoperability with the Linux
client breaks. (The program testcopy-linux.c will just loop after doing
the copy, because it never sees the expected ENXIO.)
That is why being spec. compliant is as issue. (The Linux client has shipped to
many users already.)

Thanks for the input, rick

Daniel


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