Re: [nfsv4] Server-side copy question

["J. Bruce Fields" <[e-mail]>]

On Mon, Oct 23, 2017 at 05:43:42PM -0400, Olga Kornievskaia wrote:
> 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.

Look back at what you said before....  So the problem you were
explaining (missing stable_how and verifier) was only for the short
write case?

So in the short write case it sounds like it *is* the server's
responsibility to commit.  That's weird, but as long as the short write
case is rare, maybe it's not a big deal?

Hm: "The coa_bytes_copied value indicates the number of bytes copied but
not which specific bytes have been copied."  That makes coa_bytes_copied
pretty much worthless.

I guess I'd be in favor of using the NFS_OK branch of CB_OFFLOAD
whenever a nonzero number of bytes is copied.  If less than the
requested number of bytes were copied, the client can always find out
the error (if any) by attempting to copy the rest.

--b.

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