Re: [nfsv4] Server-side copy question

[Olga Kornievskaia <[e-mail]>]

On Fri, Oct 20, 2017 at 3:33 PM, J. Bruce Fields <[e-mail]> wrote:
> On Wed, Oct 18, 2017 at 05:22:08PM -0400, Olga Kornievskaia wrote:
>> On Tue, Feb 28, 2017 at 12:32 PM, J. Bruce Fields <[e-mail]> wrote:
>> > On Tue, Feb 28, 2017 at 05:04:27PM +0000, Adamson, Andy wrote:
>> >> I also thought that bytes copied is only included in the success case – but as Olga pointed out, not true. The coa_status of NFS4_OK has the coa_resok4->wr_count showing the bytes copied, and the default (e.g. failure cases) has the coa_bytes_copied.
>> >>
>> >> So the server can send a CB_OFFLOAD with an error (such as the –EINVAL in the example) and send the bytes copied in coa_bytes_copied.
>> >>
>> >>    union offload_info4 switch (nfsstat4 coa_status) {
>> >>    case NFS4_OK:
>> >>            write_response4 coa_resok4;
>> >>    default:
>> >>            length4         coa_bytes_copied;
>> >>    };
>> >
>> > Gah, I'm sorry, Olga said CB_OFFLOAD but for some reason I was looking
>> > at COPY.
>> >
>> > I have no idea what to think of that.  I don't see why it should be
>> > different from COPY.
>>
>> I'd like to resurrect this thread...
>>
>> This discussion was initiated to allow for the server to do a partial
>> copy instead of failing the copy with EINVAL when copy is requested
>> beyond the end of the file.
>>
>> However, the problem I'm running into is that because CB_OFFLOAD only
>> returns "coa_bytes_copied" and does not include stable_how and
>> verifier. So even if client were to then send a COMMIT for the bytes
>> that were copied, it has no verifier to match from the COMMIT to
>> anything.
>>
>> Should the client then ignore the lack of the matching verifier and
>> just assume the data was committed for the partial bytes?
>
> Yes, sounds like in the asynchronous case the server has to wait for the
> writes to reach disk before calling CB_OFFLOAD.  (Do we currently do
> that?).

Why? No the spec does not require the server to do no such thing. The
server sends back in CB_OFFLOAD if the bytes were written as UNSTABLE
or FILE_SYNC.

> In theory that shouldn't be too expensive because asynchronous COPY
> should normally be done with a very large range.
>
> (I wonder if the server should just do a synchronous copy if the copy
> would be less than a few megs?)

Yes the server could determine to convert an asynchronous copy into a
synchronous one based on size.

I guess I'm still confused how to handle the implementation so that it
doesn't kill interoperability with other possible (future)
implementations...