Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754036Ab3IZSGr (ORCPT ); Thu, 26 Sep 2013 14:06:47 -0400 Received: from mail-qa0-f52.google.com ([209.85.216.52]:46419 "EHLO mail-qa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753998Ab3IZSGm (ORCPT ); Thu, 26 Sep 2013 14:06:42 -0400 MIME-Version: 1.0 X-Originating-IP: [86.59.245.170] In-Reply-To: <20130926153359.GE704@fieldses.org> 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> Date: Thu, 26 Sep 2013 20:06:41 +0200 Message-ID: Subject: Re: [RFC] extending splice for copy offloading From: Miklos Szeredi To: "J. Bruce Fields" Cc: 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1821 Lines: 37 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. And for that perhaps we need a different API, one which has been discussed some time ago: asynchronous copyfile() returns immediately with a pollable event descriptor indicating copy progress, and some way to cancel the copy. And that can internally rely on ->direct_splice(), with appropriate algorithms for determine the optimal chunk size. Thanks, Miklos -- 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/