On Mon, Jul 22, 2013 at 03:17:29PM -0400, Bryan Schumaker wrote: > On 07/22/2013 02:50 PM, J. Bruce Fields wrote: > > On Fri, Jul 19, 2013 at 05:03:49PM -0400, bjschuma@xxxxxxxxxx wrote: > >> From: Bryan Schumaker <bjschuma@xxxxxxxxxx> > >> > >> Rather than performing the copy right away, schedule it to run later and > >> reply to the client. Later, send a callback to notify the client that > >> the copy has finished. > > > > I believe you need to implement the referring triple support described > > in http://tools.ietf.org/html/rfc5661#section-2.10.6.3 to fix the race > > described in > > http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-19#section-15.1.3 > > . > > I'll re-read and re-write. > > > > > I see cb_delay initialized below, but not otherwise used. Am I missing > > anything? > > Whoops! I was using that earlier to try to fake up a callback, but I eventually decided it's easier to just do the copy asynchronously. I must have forgotten to take it out :( > > > > > What about OFFLOAD_STATUS and OFFLOAD_ABORT? > > I haven't thought out those too much... I haven't thought about a use for them on the client yet. If it might be a long-running copy, I assume the client needs the ability to abort if the caller is killed. (Dumb question: what happens on the network partition? Does the server abort the copy when it expires the client state?) In any case, http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-19#section-15.1.3 says "If a server's COPY operation returns a stateid, then the server MUST also support these operations: CB_OFFLOAD, OFFLOAD_ABORT, and OFFLOAD_STATUS." So even if we've no use for them on the client then we still need to implement them (and probably just write a basic pynfs test). Either that or update the spec. > > In some common cases the reply will be very quick, and we might be > > better off handling it synchronously. Could we implement a heuristic > > like "copy synchronously if the filesystem has special support or the > > range is less than the maximum iosize, otherwise copy asynchronously"? > > I'm sure that can be done, I'm just not sure how to do it yet... OK, thanks. --b. -- 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