On Mon, Aug 05, 2013 at 02:11:21PM -0400, J. Bruce Fields wrote: > 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. Uh, sorry, I was confused, I missed the write_response4 in the COPY result entirely. Yeah obviously that's useless. (Why's it there anyway? No client or application is going to care about anything other than whether it's 0 or not, right?) So maybe it would be useful to add a way for a server to optionally communicate a sequential bytes_written, I don't know. Without that, at least, I think the only reasonable implementation of "dumb" server-side copies will need to implement the asynchronous case (and referring triples). Which might be worth doing. But for the first cut maybe we should instead *only* implement this on btrfs (or whoever else can do quick copies). --b. > > (Unless we also got rid of the callback.) > > 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@xxxxxxxxxx > > www.netapp.com > > N?????r??y????b?X??ǧv?^?){.n?+????{???"??^n?r???z???h?????&?? ?G???h?(?階?ݢj"???m??????z?ޖ???f???h???~?m -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
