[PATCH] Make server-side copy (copy-chunk) async

[Jeremy Allison]

On Wed, Mar 22, 2017 at 10:24:39PM +0100, Ralph Böhme wrote:
> On Wed, Mar 22, 2017 at 01:22:23PM -0700, Jeremy Allison wrote:
> > On Wed, Mar 22, 2017 at 07:14:05PM +0100, Ralph Böhme via samba-technical wrote:
> > > Hi!
> > > 
> > > Attached is a patchset I've been working on that makes our server-side copy
> > > asynchronous.
> > > 
> > > At the SMB layer the chunks are processed sequentially in order, but left to
> > > right merged if copy ranges are adjecent. In the backend (vfs_default) I'm
> > > essentially just using pread|pwrite_send|recv instead of the sync versions.
> > > 
> > > I'm also adding a small new feature to tevent: cancel forwarding. It allows the
> > > implementation of a tevent request using subrequest to request forwarding of
> > > cancels to be done automagically by the tevent library. This is useful for
> > > forwarding cancels through a chain of subrequests.
> > 
> > OK. I have to ask the nasty question :-).
> > 
> > Do you *really* need to extend tevent to add this ?
> > 
> > You're only forwarding cancel to one event at a time.
> > 
> > Couldn't you just add a normal cancel function
> > on the parent req, which calls tevent_req_cancel()
> > on the subreq stored in the parent req private data ?
> 
> In the end I need the cancel to get all the way down to vfs_default, as that's
> where the actual copying takes place, potentially in a loop (fruit:copyfile
> case) copying some big file in *completely* in one subreq. *That*s the one I
> want to be able to cancle, though admittedly the client doesn't support
> cancelling a pending fruit:copyfile style copy.

I still don't see why you need to change the
tevent library to add this. Each cancel function
forwards to the next one down the stack.

Yeah it's more work, but is it a generic
feature needed to add to tevent ? It's
replacing a linking tevent_cancel function
that forwards manually to a stored subreq, right ?

What about a tevent useage where a containing
tevent_req issues a set of multiple async
sub requests backed by underlying pthreads,
or a it's using a tevent_queue ? It doesn't
help cancelling them as there's more than
one subreq we're waiting on.

I can think of different configs that might
need to do multiple-forwarding-cancels, and I'm worried
about putting something in stone that might
need extending later.

Convince me ! :-) :-).

> Cf the last commit that adds a test for this.

Yep, I saw that.