Messages in this thread | | | Date | Mon, 11 Mar 2013 02:31:35 -0700 | From | Joel Becker <> | Subject | Re: New copyfile system call - discuss before LSF? |
| |
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
| |