Re: New copyfile system call - discuss before LSF?

From: Joel Becker <jlbec@evilplan.org>
To: Zach Brown <zab@redhat.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
	Andy Lutomirski <luto@amacapital.net>,
	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>
Subject: Re: New copyfile system call - discuss before LSF?
Date: Mon, 11 Mar 2013 02:31:35 -0700	[thread overview]
Message-ID: <20130311093134.GI7783@localhost> (raw)
In-Reply-To: <20130226000301.GG1658@lenny.home.zabbo.net>

On Mon, Feb 25, 2013 at 04:03:01PM -0800, Zach Brown wrote:
> > >   I think it would be neat if it couldn't
> > > corrupt data.
> > 
> > It would also be neat if the moon were made of cheese...
> 
> And there we have the lsf2013 t-shirt slogan.  I think we're done here!
> 
> - z

Hey Everyone,
	So, of course, this thread happened while I was celebrating my
10-year anniversary on a warm, sunny island.  I won't trade.  But let me
drop my $0.02 in here.
	First, we have our T-shirt slogan.  That overrides every other
concern.
	Second, I agree that moving forward on anything is better than
not.  I haven't delivered the updated fastcopy(2) patch I promised two
years ago, and I have to admit that I can't promise code on any sane
timeframe.
	Back when I was working on this, I thought that link(2) was a
good model for a full-file copy.  Thus I came up with reflink(2).  This
eventually became the fastcopyu(2) proposal discussed two years ago.  I
did not think, and I still don't think, that we should conflate the API
for "copy/clone this file in some way" (ala fastcopy(2)) with
"duplicate/link this range of bytes" (ala BTRFS_IOC_CLONE_RANGE).  I
thought that splice(2) or something like it was a better fit for ranges;
this thread has already had the same thought.
	fastcopy(2) had a provision for CoW for atomicity, including
metadata.  This is because ocfs2 reflinks *can* provide atomic clones
with metadata included.  I would like any new proposal to allow for
that.  If it does not, of course, callers can continue to use
OCFS2_IOC_REFLINK, but I'd rather make it part of the generic behavior,
so that generic tools come with it.

Joel

-- 

"You don't make the poor richer by making the rich poorer."
	- Sir Winston Churchill

			http://www.jlbec.org/
			jlbec@evilplan.org