Re: [RFC 4/5] NFSD: Defer copying

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Aug 05, 2013 at 02:50:38PM +0000, Myklebust, Trond wrote:
> On Mon, 2013-08-05 at 10:41 -0400, J. Bruce Fields wrote:
> > Bryan suggested in offline discussion that one possibility might be to
> > copy, say, at most a gigabyte at a time before returning and making the
> > client continue the copy.
> > 
> > Where for "a gigabyte" read, "some amount that doesn't take too long to
> > copy but is still enough to allow close to full bandwidth".  Hopefully
> > that's an easy number to find.
> > 
> > But based on
> > http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-19#section-14.1.2
> > the COPY operation isn't designed for that--it doesn't give the option
> > of returning bytes_copied in the successful case.
> 
> The reason is that the spec writers did not want to force the server to
> copy the data in sequential order (or any other particular order for
> that matter).

Well, servers would still have the option not to return success unless
the whole copy succeeded, so I'm not sure this *forces* servers to do
sequential copies.

(Unless we also got rid of the callback.)

--b.

> 
> If the copy was short, then the client can't know which bytes were
> copied; they could be at the beginning of the file, in the middle, or
> even the very end. Basically, it needs to redo the entire copy in order
> to be certain.
> 
> > Maybe we should fix that in the spec, or maybe we just need to implement
> > the asynchronous case.  I guess it depends on which is easier,
> > 
> > 	a) implementing the asynchronous case (and the referring-triple
> > 	   support to fix the COPY/callback races), or
> > 	b) implementing this sort of "short copy" loop in a way that gives
> > 	   good performance.
> > 
> > On the client side it's clearly a) since you're forced to handle that
> > case anyway.  (Unless we argue that *all* copies should work that way,
> > and that the spec should ditch the asynchronous case.) On the server
> > side, b) looks easier.
> > 
> > --b.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> N?????r??y????b?X??ǧv?^?)޺{.n?+????{???"??^n?r???z?\x1a??h?????&??\x1e?G???h?\x03(?階?ݢj"??\x1a?^[m??????z?ޖ???f???h???~?m