From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756238Ab3BVIsQ (ORCPT ); Fri, 22 Feb 2013 03:48:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59442 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756135Ab3BVIsO (ORCPT ); Fri, 22 Feb 2013 03:48:14 -0500 Message-ID: <5127308C.7000209@redhat.com> Date: Fri, 22 Feb 2013 09:47:08 +0100 From: Ric Wheeler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Myklebust, Trond" CC: Ric Wheeler , Paolo Bonzini , Linux FS Devel , "linux-kernel@vger.kernel.org" , "Chris L. Mason" , Christoph Hellwig , Alexander Viro , "Martin K. Petersen" , Hannes Reinecke , Joel Becker Subject: Re: New copyfile system call - discuss before LSF? References: <512606DF.5050706@redhat.com> <4FA345DA4F4AE44899BD2B03EEEC2FA9235D998C@SACEXCMBX04-PRD.hq.netapp.com> <512635D2.4090207@redhat.com> <51267CEB.8070805@redhat.com> <51269A2B.7070000@redhat.com> <4FA345DA4F4AE44899BD2B03EEEC2FA9235DAE3B@SACEXCMBX04-PRD.hq.netapp.com> In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA9235DAE3B@SACEXCMBX04-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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