Re: New copyfile system call - discuss before LSF?

[Ric Wheeler <rwheeler@redhat.com>]

On 02/21/2013 02:51 PM, Myklebust, Trond wrote:
> On Thu, 2013-02-21 at 12:37 +0100, Ric Wheeler wrote:
>> We have debated the need to have a system call to allow for offloading copy
>> operations, for example to an NFS server (part to the new NFS 4.2
>> specification), SCSI target device (two different SCSI commands do this), local
>> file systems (reflink, etc) and I suspect many other possible parts of the stack
>> could implement this.
> sendfile64() pretty much already has the right arguments for a
> "copyfile", however it would be nice to add a 'flags' parameter: the
> NFSv4.2 version would use that to specify whether or not to copy file
> metadata.

That would seem to be enough to me and has the advantage that it is an 
relatively obvious extension to something that is at least not totally unknown 
to developers.

Do we need more than that for non-NFS paths I wonder? What does reflink need or 
the SCSI mechanism?

>
>> The earliest discussion of such a system call I saw happened back in 2001, I
>> know we had another more recent flurry (2-3 years back?) as well that got
>> tangled up and died away.
>>
>> Given the new popularity of this in storage devices and the use case for virt
>> guests, any chance to get a proposal floated this year that might be able to
>> land upstream in our life times :) ?
> I'm planning on soon dusting off the NFS prototype that NetApp wrote 3
> years ago and converting at least the client implementation into
> something that can go upstream. We do also have a server prototype for
> Linux, but the copy offload between 2 different servers is a hack and
> would need significant work.
>

That would be really interesting, thanks!