Re: [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper

[Zach Brown]

On Tue, Apr 14, 2015 at 02:19:11PM -0400, J. Bruce Fields wrote:
> On Tue, Apr 14, 2015 at 01:16:13PM -0400, Anna Schumaker wrote:
> > On 04/14/2015 12:53 PM, Christoph Hellwig wrote:
> > > On Sat, Apr 11, 2015 at 09:04:02AM -0400, Jeff Layton wrote:
> > >> Yuck! How the heck do you clean up the mess if that happens? I
> > >> guess you're just stuck redoing the copy with normal READ/WRITE?
> > >>
> > >> Maybe we need to have the interface return a hard error in that
> > >> case and not try to give back any sort of offset?
> > > 
> > > The NFSv4.2 COPY interface is a train wreck.  At least for Linux I'd
> > > expect us to simply ignore it and only implement my new CLONE
> > > operation with sane semantics.  That is unless someone can show some
> > > real life use case for the inter server copy, in which case we'll
> > > have to deal with that mess.  But getting that one right at the VFS
> > > level will be a nightmare anyway.
> > > 
> > > Make this a vote from me to not support partial copies and just
> > > return and error in that case.
> > 
> > Agreed.  Looking at the v4.2 spec, COPY does take ca_consecutive and a
> > ca_synchronous flags that let the client state if the copy should be
> > done consecutively or synchronously.  I expected to always set
> > consecutive to "true" for the Linux client.
> 
> That's supposed to mean results are well-defined in the partial-copy
> case, but I think Christoph's suggesting eliminating the partial-copy
> case entirely?
> 
> Which would be fine with me.
> 
> It might actually have been me advocating for partial copies.  But that
> was only because a partial-copy-handling-loop seemed simpler to me than
> progress callbacks if we were going to support long-running copies.
> 
> I'm happy enough not to have it at all.

Ah, OK, that's great news.

I thought at one point we were worried about very long running RPCs on
the server.  Are we not worried about that now?

Is the client expected to cut the work up into arbitrarily managable
chunks?  Is the server expected to fail COPY/CLONE requests that it
thinks would take way too long?  Something else?

- z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/