On 07/22/2013 08:55 PM, J. Bruce Fields wrote:
On Mon, Jul 22, 2013 at 03:54:00PM -0400, Bryan Schumaker wrote:
On 07/22/2013 03:43 PM, J. Bruce Fields wrote:
On Mon, Jul 22, 2013 at 03:37:00PM -0400, Bryan Schumaker wrote:
On 07/22/2013 03:30 PM, J. Bruce Fields wrote:
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.
Fair enough. I'll think it out and do something! Easy solution: save this patch for later and only support the sync version of copy for the final version of this patch series.
I can't remember--does the spec give the server a clear way to bail out
and tell the client to fall back on a normal copy in cases where the
server knows the copy could take an unreasonable amount of time?
--b.
I don't think so. Is there ever a case where copying over the network would be slower than copying on the server?
Mybe not, but if the copy will take a minute, then we don't want to tie
up an rpc slot for a minute.
--b.
I think that we need to be able to handle copies that would take a lot longer
than just a minute - this offload could take a very long time I assume depending
on the size of the data getting copied and the back end storage device....
ric
--
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
