Re: [nfsv4] Server-side copy question

[Olga Kornievskaia <[e-mail]>]

On Fri, Feb 24, 2017 at 5:21 PM, J. Bruce Fields <[e-mail]> wrote:
> On Thu, Feb 23, 2017 at 04:46:33PM -0500, David Noveck wrote:
>> > I think what we really want is to change the MUST to something weaker
>> > (MAY?).
>>
>> I think we should stay away from the question of what we really want,
>> since everybody's preferences are different.
>>
>> Fortunately, we don't need agreement/consensus on that.  Anyone,
>> can submit an errata.  All you need is a suggested corrected text that
>> people will not object strongly to and will regard as an improvement.
>> Given how broken the existing text is, that is a pretty low bar.
>>
>> I have already suggested using MAY so I'm on board.  Trond
>> had some objections but if he can't come up with something better,
>> I don't think he'll object to your approach.
>>
>> > Maybe it doesn't work, but I the intention was to allow COPY to be
>> > implemented by either a copy-like or clone-like backend.
>>
>> That's fine but the question is going to be about how such a client
>> deals with server's who manifest behavior A, mandated by RFC 7862
>> and allowed by the corrected text we are discussing.
>>
>> > So, my only worry would be to avoid clients that are unprepared to deal
>> > with a short read.  Thankfully I think short reads are already allowed
>> > for other reasons, so I think the risk of a major interoperability
>> > problem here is low?
>>
>> Given that this only occurs in the range case, which is quite rarely used,
>> the chance of a "major" interoperability problem is not low or
>> infinitesimal.
>> It is zero.
>
> The Linux server implementation currently caps the amount of data copied
> at 4MB, returning a short result instead, to prevent arbitrary long
> copies.  (Partly because we didn't want to implement async copy at
> first.)
>
> So an app might do something like:
>
>         offset = 0;
>         while (copied = copy_file_range(fdin, offset, fdout, offset,
>                                                         len, flags) > 0)
>                 offset += copied;
>
> So I expect the range case to be the normal case there even when copying
> the whole file.  But we're also counting on clients and apps to handle
> short copy results.
>
> (Hm, linux's copy_file_range isn't documented to have the "0 == copy to
> end of file convention".  That's a potentially ugly mismatch?  Not sure
> if our API can or should be fixed.)
>
> The possibility that the copy could return either a short read or EINVAL
> make this all kind of annoying.  You might end up having to do something
> like
>
>         offset = 0;
>         while (1) {
>                 copied = copy_file_range(fdin, offset, fdout, offset,
>                                                         len, flags) > 0)
>                 if (copied == -EINVAL) {
>                         /* Uh, I dunno, maybe stat the file for a new
>                          * length and retry? */

Bruce, just checking in general for returned EINVAL isn't great
because there is also the case when the source offset is beyond the
end of the file. So now we are forcing the client (application) to
distinguish between this case that is not OK and another case where it
might be ok?

>                 } else if (copied < 0)
>                         /* error out */
>                 else
>                         offset += copied;
>         }
>
> But, anyway, I guess that's doable.

An an implementor, I'm still a bit confused about the direction to
take especially on the client side. On the server side, I'm concluding
from this discussion that it's beneficial to ignore the error of
copying beyond the end of the file and returning to the client a
partial copy.

On the client side, I see 3 possibilities that the client can receive
in asynchronous copy case

say client sent COPY bytes 0-100 but say there are only 50bytes in the file.
server can send back
1. CB_OFFLOAD status NFS4_OK bytes copied 50.
 -- given that client needs to be prepared for a short read anyway,
should it retry from offset 50 and now offset is beyond the end of the
file and should the whole copy fail?
2. CB_OFFLOAD status EINVAL bytes copied 50.
 -- should the client application (or the NFS layer) fail since EINVAL
was returned or should it ignore it and return success to the user?
3. CB_OFFLOAD status EINVAL bytes copied -1 (or 0).
  -- this is the case where the server strictly enforces the current
spec. This is the clearest case, client can't do anything but fail.

>
> --b.
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4