From: Ric Wheeler <rwheeler@redhat.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Ric Wheeler <rwheeler@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Chris L. Mason" <clmason@fusionio.com>,
Christoph Hellwig <hch@infradead.org>,
Alexander Viro <aviro@redhat.com>,
"Martin K. Petersen" <mkp@mkp.net>,
Hannes Reinecke <hare@suse.de>, Joel Becker <jlbec@evilplan.org>
Subject: Re: New copyfile system call - discuss before LSF?
Date: Fri, 22 Feb 2013 09:47:08 +0100 [thread overview]
Message-ID: <5127308C.7000209@redhat.com> (raw)
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA9235DAE3B@SACEXCMBX04-PRD.hq.netapp.com>
On 02/21/2013 11:13 PM, Myklebust, Trond wrote:
> On Thu, 2013-02-21 at 23:05 +0100, Ric Wheeler wrote:
>> On 02/21/2013 09:00 PM, Paolo Bonzini wrote:
>>> Il 21/02/2013 15:57, Ric Wheeler ha scritto:
>>>>> 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?
>>> For virt we would like to be able to specify arbitrary block ranges.
>>> Copying an entire file helps some copy operations like storage
>>> migration. However, it is not enough to convert the guest's offloaded
>>> copies to host-side offloaded copies.
>>>
>>> Paolo
>> I don't think that the NFS protocol allows arbitrary ranges, but the SCSI
>> commands are ranged based.
>>
>> If I remember what the windows people said at a SNIA event a few years back,
>> they have a requirement that the target file be pre-allocated (at least for the
>> SCSI based copy). Not clear to me where they iterate over that target file to do
>> the block range copies, but I suspect it is in their kernel.
> The NFSv4.2 copy offload protocol _does_ allow the copying of arbitrary
> byte ranges. The main target for that functionality is indeed
> virtualisation and thin provisioning of virtual machines.
>
For background, here is a pointer to Fred Knight's SNIA talk on the SCSI support
for offload:
https://snia.org/sites/default/files2/SDC2011/presentations/monday/FrederickKnight_Storage_Data_Movement_Offload.pdf
and a talk from Spencer Shepler that gives some detail on the NFS spec,
including the "server side copy" bits:
https://snia.org/sites/default/files2/SDC2011/presentations/wednesday/SpencerShepler_IETF_NFSv4_Working_Group_v4.pdf
The talks both have references to the actual specs for the gory details.
Ric
next prev parent reply other threads:[~2013-02-22 8:47 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 11:37 New copyfile system call - discuss before LSF? Ric Wheeler
2013-02-21 13:37 ` Hannes Reinecke
2013-02-21 13:51 ` Myklebust, Trond
2013-02-21 14:57 ` Ric Wheeler
2013-02-21 16:36 ` Andreas Dilger
2013-02-21 20:00 ` Paolo Bonzini
2013-02-21 20:50 ` Myklebust, Trond
2013-02-21 22:24 ` Zach Brown
2013-02-22 1:29 ` Myklebust, Trond
2013-02-23 0:32 ` Eric Wong
2013-03-30 19:45 ` Pavel Machek
2013-03-31 21:23 ` Eric Wong
2013-02-22 9:47 ` Paolo Bonzini
2013-02-22 9:52 ` Ric Wheeler
2013-02-22 18:22 ` Zach Brown
2013-02-22 22:48 ` Myklebust, Trond
2013-02-25 21:14 ` Andy Lutomirski
2013-02-25 21:49 ` Ric Wheeler
2013-02-25 21:59 ` Myklebust, Trond
2013-02-25 22:16 ` Andy Lutomirski
2013-02-25 23:28 ` Myklebust, Trond
2013-02-25 23:35 ` Andy Lutomirski
2013-02-25 23:45 ` Myklebust, Trond
2013-02-26 0:03 ` Zach Brown
2013-03-11 9:31 ` Joel Becker
2013-02-26 21:02 ` Jörn Engel
2013-02-26 22:35 ` Andy Lutomirski
2013-03-30 19:49 ` Pavel Machek
2013-03-30 20:08 ` Andreas Dilger
2013-03-30 21:45 ` Pavel Machek
2013-03-30 21:57 ` Myklebust, Trond
2013-03-30 23:21 ` Ric Wheeler
2013-03-31 2:53 ` Andreas Dilger
2013-03-31 3:52 ` Myklebust, Trond
2013-03-31 4:18 ` Andy Lutomirski
2013-03-31 4:36 ` Myklebust, Trond
2013-03-31 4:45 ` Myklebust, Trond
2013-04-01 15:49 ` J. Bruce Fields
2013-03-31 7:36 ` Pavel Machek
2013-03-31 18:27 ` Myklebust, Trond
2013-03-31 18:32 ` openat(..., AT_UNLINKED) was " Pavel Machek
2013-03-31 18:44 ` Myklebust, Trond
2013-03-31 22:50 ` Pavel Machek
2013-03-31 23:14 ` Ric Wheeler
2013-03-31 23:18 ` Pavel Machek
2013-03-31 23:28 ` Ric Wheeler
2013-03-31 23:41 ` Pavel Machek
2013-03-31 5:38 ` AEDilger Gmail
2013-03-31 8:25 ` Pavel Machek
2013-03-31 11:48 ` Pádraig Brady
2013-03-30 22:40 ` Andy Lutomirski
2013-02-21 22:05 ` Ric Wheeler
2013-02-21 22:13 ` Myklebust, Trond
2013-02-22 8:47 ` Ric Wheeler [this message]
2013-02-21 18:29 ` Jeremy Allison
2013-02-22 0:29 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5127308C.7000209@redhat.com \
--to=rwheeler@redhat.com \
--cc=Trond.Myklebust@netapp.com \
--cc=aviro@redhat.com \
--cc=clmason@fusionio.com \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=jlbec@evilplan.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkp@mkp.net \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.