Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752580Ab3JFImm (ORCPT ); Sun, 6 Oct 2013 04:42:42 -0400 Received: from mail-ob0-f182.google.com ([209.85.214.182]:44431 "EHLO mail-ob0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752062Ab3JFImi convert rfc822-to-8bit (ORCPT ); Sun, 6 Oct 2013 04:42:38 -0400 Date: Sun, 06 Oct 2013 03:42:35 -0500 From: Rob Landley Subject: Re: [RFC] extending splice for copy offloading To: Miklos Szeredi Cc: "J. Bruce Fields" , Zach Brown , Anna Schumaker , Kernel Mailing List , Linux-Fsdevel , "linux-nfs@vger.kernel.org" , Trond Myklebust , Bryan Schumaker , "Martin K. Petersen" , Jens Axboe , Mark Fasheh , Joel Becker , Eric Wong References: <1378919210-10372-1-git-send-email-zab@redhat.com> <20130925183828.GA30372@lenny.home.zabbo.net> <20130925190620.GB30372@lenny.home.zabbo.net> <20130925195526.GA18971@fieldses.org> <20130925210742.GG30372@lenny.home.zabbo.net> <20130926153359.GE704@fieldses.org> In-Reply-To: (from miklos@szeredi.hu on Thu Sep 26 13:06:41 2013) X-Mailer: Balsa 2.4.11 Message-Id: <1381048955.1974.171@driftwood> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1990 Lines: 47 On 09/26/2013 01:06:41 PM, Miklos Szeredi wrote: > On Thu, Sep 26, 2013 at 5:34 PM, J. Bruce Fields > wrote: > > On Thu, Sep 26, 2013 at 10:58:05AM +0200, Miklos Szeredi wrote: > >> On Wed, Sep 25, 2013 at 11:07 PM, Zach Brown > wrote: > >> >> A client-side copy will be slower, but I guess it does have the > >> >> advantage that the application can track progress to some > degree, and > >> >> abort it fairly quickly without leaving the file in a totally > undefined > >> >> state--and both might be useful if the copy's not a simple > constant-time > >> >> operation. > >> > > >> > I suppose, but can't the app achieve a nice middle ground by > copying the > >> > file in smaller syscalls? Avoid bulk data motion back to the > client, > >> > but still get notification every, I dunno, few hundred meg? > >> > >> Yes. And if "cp" could just be switched from a read+write syscall > >> pair to a single splice syscall using the same buffer size. > > > > Will the various magic fs-specific copy operations become > inefficient > > when the range copied is too small? > > We could treat spice-copy operations just like write operations (can > be buffered, coalesced, synced). > > But I'm not sure it's worth the effort; 99% of the use of this > interface will be copying whole files. My "patch" implementation (in busybox and toybox) hits a point where it wants to copy the rest of the file, once there are no more hunks to apply. This is not copying a whole file. A similar thing happens with tail when you use the +N syntax to skip start instead of end lines. I can see sed doing a similar thing when told to operate on line ranges... Note sure your 99% holds up here. Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/