On Aug 5, 2013, at 2:11 PM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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. > > (Unless we also got rid of the callback.) If the client initiates a full-file copy and the operation fails, I would think that the client itself can try copying sufficiently large chunks of the file via separate individual COPY operations. If any of those operations fails, then the client can fall back again to a traditional over-the-wire copy operation. > --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@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 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
