From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: copy offload support in Linux - new system call needed? Date: Wed, 14 Dec 2011 19:27:39 +0000 Message-ID: <20111214192739.GN2203@ZenIV.linux.org.uk> References: <4EE8F75F.6070800@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "linux-scsi@vger.kernel.org" , linux-fsdevel , Hannes Reinecke , Andrew Morton , linux-nfs@vger.kernel.org, Joel Becker , James Bottomley To: Ric Wheeler Return-path: Content-Disposition: inline In-Reply-To: <4EE8F75F.6070800@gmail.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Dec 14, 2011 at 02:22:07PM -0500, Ric Wheeler wrote: > We had an active thread a couple of years back that came out of the > reflink work and, at the time, there seemed to be moderately > positive support for adding a new system call that would fit this > use case (Joel Becker's copyfile()). > > Can we resurrect this effort? Is copyfile() still a good way to go, > or should we look at other hooks? copyfile(2) is probably a good way to go, provided that we do _not_ go baroque as it had happened the last time syscall had been discussed. IOW, to hell with progress reports, etc. - just a fastpath kind of thing, in the same kind of relationship to cp(1) as rename(2) is to mv(1). If it works - fine, if not - caller has to be ready to deal with handling cross-device case anyway.