From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: New copyfile system call - discuss before LSF? Date: Mon, 11 Mar 2013 02:31:35 -0700 Message-ID: <20130311093134.GI7783@localhost> References: <4FA345DA4F4AE44899BD2B03EEEC2FA9235DAA99@SACEXCMBX04-PRD.hq.netapp.com> <20130221222449.GY22221@lenny.home.zabbo.net> <512BD44C.40907@amacapital.net> <512BDC82.5060203@redhat.com> <4FA345DA4F4AE44899BD2B03EEEC2FA928699C17@sacexcmbx05-prd.hq.netapp.com> <4FA345DA4F4AE44899BD2B03EEEC2FA92869CE90@sacexcmbx05-prd.hq.netapp.com> <4FA345DA4F4AE44899BD2B03EEEC2FA92869CFCE@sacexcmbx05-prd.hq.netapp.com> <20130226000301.GG1658@lenny.home.zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Myklebust, Trond" , Andy Lutomirski , Ric Wheeler , Paolo Bonzini , Linux FS Devel , "linux-kernel@vger.kernel.org" , "Chris L. Mason" , Christoph Hellwig , Alexander Viro , "Martin K. Petersen" , Hannes Reinecke To: Zach Brown Return-path: Content-Disposition: inline In-Reply-To: <20130226000301.GG1658@lenny.home.zabbo.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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