On Mon, 2013-08-05 at 14:17 -0400, Chuck Lever wrote: > 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. How does the client determine what constitutes a "sufficiently large chunk" in the mind of the server, and why do we want to add that functionality in the first place? Fallback to traditional copy in the case where the server doesn't support offload is fine, but all these screwball special cases are not. We already have sync vs async. Now you want to add chunked sync and chunked async too? NACK... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
