Subject: Re: [nfsv4] NFSv4.2 server replies to Copy with length == 0

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Oct 2019 02:16:36 +0000

I have added [email-masked] to the cc list, since I think it is important that
everyone involved in NFSv4.2 be aware of this.

>J. Bruce Fields wrote:
>On Wed, Oct 16, 2019 at 07:53:45PM +0000, Kornievskaia, Olga wrote:
>> On 10/16/19, 11:58 AM, "J. Bruce Fields" <[email-masked]> wrote:
>>     On Wed, Oct 16, 2019 at 06:22:42AM +0000, Rick Macklem wrote:
>>     > It seems that the Copy reply with wr_count == 0 occurs when the
>>     > client sends a Copy request with ca_src_offset beyond EOF in the
>>     > input file.  (It happened because I was testing an old/broken
>>     > version of my client, but I can reproduce it, if you need a
>>     > bugfix to be tested. I don't know if the case of
>>     > ca_src_offset+ca_count beyond EOF behaves the same?) --> The RFC
>>     > seems to require a reply of NFS4ERR_INVAL for this case.
>>
>>     I've never understood that INVAL requirement.  But I know it's
>>     been discussed before, maybe there was some justification for it
>>     that I've forgotten.
No longer overly relevant, since the RFC is now a published spec.
(It may have just been consistent with the old copy_file_range(2) semantics?)

>>
>> Sigh, well, I don’t know if we should consider adding the check to the
>> NFS server to be NFS spec compliant. VFS layer didn't want the check
>> and instead the preference has been to keep read() semantics of
>> returning a short read (when the len was beyond the end of the file or
>> if the source) to something beyond the end of the file.
>
>I'm inclined to think the spec's just wrong.
The RFC is not wrong, although it might not be your preferred semantic.
(It would only be wrong if it was unimplementable.)

As for patching the server, I am not sure if that is a good idea now or not?
- I would like to see the Linux NFSv4.2 server conform to the RFC, however
   it has already shipped in its current form.
--> I think that all extant clients need to handle both reply semantics and,
       once that is the case, patching the server to conform to the RFC would
       be nice.

I have now found two cases where the Linux NFSv4.2 server does not conform
to RFC-7862. One is as above and the other is a reply to Seek of NFS4ERR_NXIO
when the sa_offset argument == file_size (instead of replying NFS_OK along
with sr_eof == true).

Since I now know about these two cases, I can code the client to handle
both of them. Of course, I do worry about others that I have not found yet.

>And how else could a client possibly interpret a 0 return?
The FreeBSD client looped, because it does a Copy in a loop until all bytes
were copied and, with a reply length == 0, it didn't make progress or
recognize an error.

Fortunately, this client is still under development (not yet released), so I can
add code to handle wr_count == 0 in the same way as NFS4ERR_INVAL.

>> On the client if VFS did read of len=0 then VFS itself we return 0,
>> thus this doesn't protect against other clients sending an NFS copy
>> with len=0.  And in NFS, receiving copy with len=0 means copy to the
>> end of the file. It's not implemented for any "intra" or "inter" code.
Are you saying that an NFSv4.2 Copy request with a ca_count == 0
will not work for the Linux NFSv4.2 server?
(I guess I'd better test this one, too.)

>A call with len=0 sounds like a different case.
>
>--b.

rick

---

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Oct 2019 04:43:58 +0000

>(I guess I'd better test this one, too.)
Tested it and it does not work, at least for Fedora30.
The server just returns 0 instead of doing a copy to EOF on the input file.
I think you should implement this, although my client does not do this now.

>>A call with len=0 sounds like a different case.
Yes, as above.

rick

---

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Oct 2019 04:46:31 +0000

I added [email-masked] as a cc, but since it hasn't been posted, here it is.

Yes, as above.

rick

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 17 Oct 2019 10:49:21 -0400

> I think you should implement this, although my client does not do this now.

Agreed.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 17 Oct 2019 11:22:53 -0400

On Thu, Oct 17, 2019 at 02:16:36AM +0000, Rick Macklem wrote:
> I have now found two cases where the Linux NFSv4.2 server does not
> conform to RFC-7862. One is as above and the other is a reply to Seek
> of NFS4ERR_NXIO when the sa_offset argument == file_size (instead of
> replying NFS_OK along with sr_eof == true).

Huh.  Looks like that's documented behavior of Linux's seek.  (See the
ERRORS section of the lseek(2) man page.)  Looks like Solaris also
returns -ENXIO in this case:

	https://docs.oracle.com/cd/E26502_01/html/E29032/lseek-2.html

And freebsd too:

	https://www.freebsd.org/cgi/man.cgi?query=lseek&sektion=2

I wonder where that spec language came from?

Our NFS server could translate an -ENXIO return into 0 and sr_eof ==
true easily enough, assuming -ENXIO is really only ever returned in that
case.

I haven't tested, but from a quick check of the Linux client code I
think that would require a matching fix on the client side to translate
sr_eof == 0 *back* to ENXIO.

I don't know if it's worth it.

--b.

---

From: Tom Talpey <[email-masked]>
Date: Thu, 17 Oct 2019 11:39:02 -0400

> I wonder where that spec language came from?

Those manpages look like ENXIO comes back only on sparse files. Perhaps
this is boilerplate from v4.0 before this kind of thing was common.

This should at least be discussed on [email-masked]...

> I don't know if it's worth it.

What Bad Thing would happen for the difference?

---

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Oct 2019 15:55:28 +0000

>I wonder where that spec language came from?
Agreed that it is the POSIX draft behaviour.
And, yes, I don't know why the RFC specifies it differently, but when I discussed
it on [email-masked], the concensus was that the RFC indicated a reply
of:
  NFS_OK, sr_eof == true, sr_offset == file_size
for a request of:
  sa_offset == file_size, sa_what == NFS4_CONTENT_DATA
(In the [email-masked] archive dated around 2019-08-12.)

>I don't know if it's worth it.
Yep, agreed. All the FreeBSD client does is what you stated above, mapping
sr_eof == true -> ENXIO for the NFS4_CONTENT_DATA case.

rick
ps: When I re-read it, the comment I made related to Bruce's "wrong" was
      blunt (or maybe rude). I apologize for the tone. All I had intended to
      say was "although it might not be our preferred semantic, it appears
      to clear and implementable, so I do not think it can be "clarified" to
      be the way the Linux server does it". I actually prefer the way the Linux
      server does it, but it is too late now, imho.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 17 Oct 2019 12:14:46 -0400

On Thu, Oct 17, 2019 at 03:55:28PM +0000, Rick Macklem wrote:
> ps: When I re-read it, the comment I made related to Bruce's "wrong"
> was blunt (or maybe rude).

It's OK!  I'm possibly being annoying about this kinda trivial thing
anyway.

> I apologize for the tone. All I had intended to say was "although it
> might not be our preferred semantic, it appears to clear and
> implementable, so I do not think it can be "clarified" to be the way
> the Linux server does it". I actually prefer the way the Linux server
> does it, but it is too late now, imho.

For the COPY case at least, implementations seem to be rare and new.

Is it really that trivial to fix up the mismatch?

Actually, I guess so: if I'm implementing the copy using read and write,
then a 0-length read result from a nonzero read call can only mean end
of file, so there's no need to do a second check of the file length or
anything.

Hm.

--b.

---

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Oct 2019 16:20:17 +0000

>this is boilerplate from v4.0 before this kind of thing was common.
As far as I know, a non-sparse file (no holes) behaves the same as a file with
holes in it. (I'm not sure if the POSIX draft is clear for the case where the
file system does not support holes, but I think most implementations handle
that the same way as a file with no holes on a file system that supports holes.)

>This should at least be discussed on [email-masked]...
I think there needs to be a discussion on how to best deal with cases where
implementations have shipped to users with these glitches in them.

I think it might be better to document them, so that client coders can
implement work arounds (I am doing so for the three cases I've found)
instead of the server being patched to change its behaviour, causing
potentially more interoperability issues.
(That's why I re-posted this to [email-masked].)

>What Bad Thing would happen for the difference?
Well, for a POSIX draft style client, the only effect is that a client may be
broken (not handle the sr_eof == true reply correctly) without the
implementors knowing that, since they tested against the Linux server.
(I believe this is the current status of the Linux client.)

For a server implementor (I get to wear both hats;-), the server can only
generate one reply or the other. I've implemented both with a tunable
that can be used to flip between them. I default to the NFS4ERR_NXIO
reply, since that is what the Linux client expects.

As for the Copy issues, the client can easily handle them, but the client
coder needs to know about them.
At this time the FreeBSD server code only implements what is in the RFC.
This seems sufficient for the testing I've done sofar.
The case that I think will break would be Linux code that does a
copy_file_range(infd, NULL, outfd, NULL, INT_MAX, 0) to copy an entire
file. I'll test this case to-day, but I'm think it will just get a NFS4ERR_INVAL
reply from the FreeBSD server.
(I can make this work for the Linux client, but it will take another "cheat"
 enabled via a tunable.)
--> Part of the confusion here comes from the fact that the Linux syscall
       semantics for copy_file_range() has changed. (I also where the
       copy_file_range(2) hat for FreeBSD, so I've got some work to do there, too.)

In summary, I think that, since Linux has been shipping this for some time,
documenting workarounds is a practical approach.

rick

---

From: Olga Kornievskaia <[email-masked]>
Date: Thu, 17 Oct 2019 13:15:37 -0400

> reply from the FreeBSD server.

this might be problematic for the linux client because though there
isn't an official use of it but the libc cp might implement this doing
exactly what you say here copy_file_range(infd, NULL, outfd, NULL,
INT_MAX, 0). It doesn't try to determine the size of the file before
the copy and
just copy max bytes assuming that it'll get a short read at some point.

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

---

From: Rick Macklem <[email-masked]>
Date: Thu, 17 Oct 2019 21:34:49 +0000

Olga Kornievskaia wrote:
>On Thu, Oct 17, 2019 at 12:20 PM Rick Macklem <[email-masked]> >wrote:
>>
>> Tom Talpey wrote:
I just tested this and the Linux client does send a Copy with a
ca_count == INT_MAX.

Truth be told, it worked fine, because my server code neglected to do the
required ca_src_offset + ca_count > file_size --> NFS4ERR_INVAL.
I'm now adding the check, but it will only be enabled by a tunable not
set by default.

I am going to post on [email-masked], to see if we can just "clarify" the RFC
to do what Linux already does.

rick

---

From: Tom Talpey <[email-masked]>
Date: Fri, 18 Oct 2019 16:26:37 -0400

> to do what Linux already does.

Technically speaking, this is not Linux behavior but libc's. Of course,
this may be a moot distinction, because changing applications can be
even harder than changing kernels. But for IETF discussion purposes
I don't think it's relevant to lump it into "Linux behavior".

Question though. Could the Linux kernel client recognize this type of
API request, and morph it into a valid NFS wire operation? Such "torque
conversion" is basically the client's job, after all.

Tom.

---

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 18 Oct 2019 16:50:50 -0400

> conversion" is basically the client's job, after all.

I believe the reason the (userland) client would do a copy of INT_MAX
bytes is because it want to avoid trying to query the size of the file
then copying only that amount of bytes since the file size could have
changed between the query and the copy. Same reason even in the kernel
we'd rather not query and then copy.

While linux server doesn't implement count=0 copy and in theory it
probably should, what the (nfs kernel) client can do if it receives a
request from VFS to copy INT_MAX it can translate that to count=0
copy.

The problem we currently face of having two different ways of doing a
copy: a traditional copy which if at some point requests beyond the
end of the file it doesn't expect to fail and expects a short read vs
doing something like copy_file_range() that uses the nfs copy_offload
that if that were to read beyond the end of the input file and if the
NFS spec reqs are enforced it would fail with EINVAL. That creates
inconsistent results using different copy mechanisms.

---

From: Tom Talpey <[email-masked]>
Date: Fri, 18 Oct 2019 17:49:52 -0400

> we'd rather not query and then copy.

The application (which is not the same as the client) is simply
expressing its request to copy the entire file. That's perfectly
natural for a local API.

The kernel client could just as easily translate this to a valid NFS
copy by pulling the size from its attribute cache, or sending a getattr
and using the result. After all, the copy operation is expensive and
long-running, it's basically no extra overhead.

In other words, I don't buy the argument that this can't and shouldn't
be done.

> inconsistent results using different copy mechanisms.

Ok, this is significant, the operations arguably should have similar
semantics. But, if there's a simple set of required processing that
the client isn't doing, which will erase the difference, why not do
those?

Tom.

---

From: Rick Macklem <[email-masked]>
Date: Fri, 18 Oct 2019 23:27:17 +0000

First off, I hope you don't mind a top post.
Just to make sure it is clear, in my opinion, the discussion below is not
addressing the "real problem".

The "real problem" is that, even if the Linux folks patched their code
tomorrow (obviously an optimistic bound;-), there are who knows how many
installed systems out there doing it the Linux way and working for their users
just fine.
--> Now, maybe the client coders can be clever enough to make their
      clients work both ways, but that isn't going to be trivial.
      - For example, if a client sends one of these Linux servers a Copy with
         length == 0, it simply replies with 0 bytes copied. Then if the client
         thinks the offset was < file_size, it could try again with
         length = INT_MAX and see if that works. (If it can figure out which works,
         then it can use that for that mount/server.)
But as you can see, it could get messy (and fail for cases where the file_size
does change, resulting in the client choosing the wrong method, etc).

To me, the problem isn't whether or not Linux can be patched to conform
to the RFC, it is "what do you do to keep the installed base that does not
conform to the RFC working?".

Right now we seem to have a Linux client which works fine with a Linux server
and works fine with other servers that don't yet support NFSv4.2.

What will I do. Make my code interoperate with Linux and not just
Linux-future (or whatever it's called) because that's what most users
will care about. (There will probably be some tunable that can be enabled
to conform to the RFC, but I'll bet no one ever uses it.)
 
So what can be done. Well, I'm a pragmatist, so I say "if there isn't an installed
base of NFSv4.2 implementations that conform to the RFC, then just redefine
the RFC to conform to the installed base, aka Linux". Anything else is going to
be messy and, unless the Linux folks buy into it, irrelevant imho.
(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-masked] about it.)

rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Tom Talpey <[email-masked]>
Sent: Friday, October 18, 2019 5:49 PM
To: [email-masked]
Subject: Re: [nfsv4] NFSv4.2 server replies to Copy with length == 0

Tom.

---

From: Rick Macklem <[email-masked]>
Date: Sat, 19 Oct 2019 02:37:14 +0000

Oh, I should clarify that I think building a client that works with both the
Linux server and one that follows the RFC is possible and that is what I
am doing w.r.t. client.
- For example, it is clipping the length to file_size - offset, not doing a Copy
   on the wire when offset >= file_size and never putting a Copy with length
   equal 0 on the wire. (Not ideal, but seems to work ok.)

It is the server that can only be Linux style or RFC style and that is where the
tunable to choose between them comes in. (It needs to be "Linux style" to
work well with a Linux server.)

rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Rick Macklem <[email-masked]>
Sent: Friday, October 18, 2019 7:27 PM
To: Tom Talpey; [email-masked]
Subject: Re: [nfsv4] NFSv4.2 server replies to Copy with length == 0

rick

Tom.

---

From: Rick Macklem <[email-masked]>
Date: Sat, 19 Oct 2019 04:51:17 +0000

Btw, attached is a little program that demonstrates the two bigger
problems. It can be built with -DBIGCOPY or without it. When built
either way on Fedora30, it works correctly for a local fs or NFSv4.2
mount to a Linux style server.

If you run it on a mount to an RFC style server, it breaks in one of
two ways:
- Built without -DBIGCOPY, it does the copy, but then loops until
   you kill it with <ctrl>C.
- Built with -DBIGCOPY, the copy fails.

It would be nice to run this on a Linux system NFSv4.2 mounted to
any other extant NFSv4.2 server out there.

rick

Sent: Friday, October 18, 2019 10:37 PM

rick

rick

Tom.

---

From: Tom Talpey <[email-masked]>
Date: Sun, 20 Oct 2019 15:21:20 -0400

> work well with a Linux server.)

I applaud the effort, but I ask please don't deploy such a client. It
will serve only to prolong the indecision of what the protocol should
be. The IETF process should define its path.

Tom.

---

From: David Noveck <[email-masked]>
Date: Mon, 21 Oct 2019 06:38:28 -0400

> The IETF process should define its path.

I agree.   For us to do that, I suggest that Rick send out a proposal
for what the spec should say and why it should say that that the working
group can discuss.

Any such proposal would need to mention that the proposed
replacement text is compatible with all existing clients and
that no existing client depends on the server obeying the current
"MUST" regarding EINVAL.   However, those facts, while relevant,
cannot be the focus of the proposal.

Given the realities of the IETF process, it would take a while
for any such proposal to effectively change the current spec
language.   During that time. clients might reasonably be
adapted to both the existing spec, and the new proposal, just as
Rick is expecting to do with his client.

With regard to servers developed before the change becomes
effective implementers will have to decide whether to obey the
existing "MUST".   Here I think the relevant fact is not that there are
particular clients that do not depend on the server obeying the "MUST",
but that it is hard to imagine any client depending on this "MUST",
which is part of the RFC2119 definition of "MUST", making use of the
word "MUST"  in this case dubious.  Perhaps an errata can be submitted to
warn potential implemeners that this requirement is under active
discussion.
I am assuming the errata would still be visible to potential implementers,
even if it is "HELD OVER", as I expect it to be.

---

From: "Frank Filz" <[email-masked]>
Date: Mon, 21 Oct 2019 07:10:56 -0700

> (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-masked] 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.

Frank

---

From: Rick Macklem <[email-masked]>
Date: Mon, 21 Oct 2019 14:24:12 +0000

sofar,
but
>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.)

Has this code shipped to users yet?

Thanks for the input, rick

Frank

---

From: Rick Macklem <[email-masked]>
Date: Mon, 21 Oct 2019 14:27:24 +0000

>for what the spec should say and why it should say that that the working
Ok, I will try. Not having done this before, what is the preferred format?
(I have no experience with the ietf editing tools, but will take a stab at it.)

Thanks, rick

warn potential implemeners that this requirement is under active discussion.

On Sun, Oct 20, 2019 at 3:21 PM Tom Talpey <[email-masked]<mailto:[email-masked]>> wrote:

Tom.

> From: nfsv4 <[email-masked]<mailto:[email-masked]>> on behalf of Rick Macklem <[email-masked]<mailto:[email-masked]>>
> To: Tom Talpey; [email-masked]<mailto:[email-masked]>
> no one has posted on [email-masked]<mailto:[email-masked]> about it.)
>
> rick
>
> From: nfsv4 <[email-masked]<mailto:[email-masked]>> on behalf of Tom Talpey <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>
>> On Fri, Oct 18, 2019 at 4:26 PM Tom Talpey <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> On Thu, Oct 17, 2019 at 12:20 PM Rick Macklem <[email-masked]<mailto:[email-masked]>> >wrote:
>>>>>>
>>>>>> Tom Talpey wrote:
>>>>>> (That's why I re-posted this to [email-masked]<mailto:[email-masked]>.)
>>>>>>
>>>> I am going to post on [email-masked]<mailto:[email-masked]>, to see if we can just "clarify" the RFC
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 21 Oct 2019 10:51:56 -0400

> long-running, it's basically no extra overhead.

Even if the kernel checks the size of the file, there is nothing that
prevents that size from changing (ie, racing truncate) so even then a
copy call with a "historically correct" offsets and length would still
get EINVAL.

---

From: Tom Talpey <[email-masked]>
Date: Mon, 21 Oct 2019 11:03:27 -0400

> copy call with a "historically correct" offsets and length would still

That is no different from any other NFS operation. In fact, it is
arguably correct that the operation should fail in such a case.

If the client needs sharing protection, it needs to take a lock, lease
or whatever. The core protocol already defines these.

Tom.

---

From: Daniel Gryniewicz <[email-masked]>
Date: Mon, 21 Oct 2019 11:44:25 -0400

> (If it is (B), the code I posted will break when run on a Linux client

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.

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

Daniel

---

From: David Noveck <[email-masked]>
Date: Mon, 21 Oct 2019 12:13:59 -0400

I guess the IETF would prefer an individual draft in the .xml format
accepted
by xml2rfc.    However, if you don't have the time to learn all that, I
think an email
saying what the spec should say and why would be good to move the process
forward by providing a focus for working group discussion.

Ultimately we would need a replacement document arrived at by editing
the .xml for rfc7862.   However, there isn't much point in doing that
until the working group decides that a significant change is needed.

On Mon, Oct 21, 2019 at 10:27 AM Rick Macklem <[email-masked]> wrote:

> > From: nfsv4 <[email-masked]<mailto:[email-masked]>> on
> behalf of Rick Macklem <[email-masked]<mailto:[email-masked]>>
> sofar, there
> > From: nfsv4 <[email-masked]<mailto:[email-masked]>> on
> behalf of Tom Talpey <[email-masked]<mailto:[email-masked]>>

---

From: spencer shepler <[email-masked]>
Date: Mon, 21 Oct 2019 09:26:33 -0700

As working group co-chair, my recommendation is that the discussion be
completed on the WG alias and then an errata filed to track the needed
change.  The document work can come after that as time and editors afford.

Spencer

On Mon, Oct 21, 2019 at 9:14 AM David Noveck <[email-masked]> wrote:

>> discussion..
>> On Sun, Oct 20, 2019 at 3:21 PM Tom Talpey <[email-masked]
>> <tom@talpey..com><mailto:[email-masked]>> wrote:
>> behalf of Rick Macklem <[email-masked]<mailto:[email-masked]
>> >>
>> >>>>>> reply, since that is what the Linux client expects..
>> >>>>>>
>> >>> nfsv4@ietf..org <[email-masked]><mailto:[email-masked]>

---

From: "Frank Filz" <[email-masked]>
Date: Mon, 21 Oct 2019 09:42:37 -0700

> -----Original Message-----
> From: Daniel Gryniewicz [mailto:[email-masked]]
> Sent: Monday, October 21, 2019 8:44 AM
> To: Rick Macklem <[email-masked]>; Frank Filz
> <[email-masked]>; 'Tom Talpey' <[email-masked]>; [email-masked]
> >> 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>
> 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.

> 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

---

From: Rick Macklem <[email-masked]>
Date: Tue, 22 Oct 2019 02:08:29 +0000

>> Reply that Linux client expects:
    Oops, it should be NFS4ERR_NXIO here.
>this check.  So we currently to neither of those two things.
Yes, this is the Linux way.

>of changing our behavior to be spec compliant, anyway, so we're happy to
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.)

Daniel