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@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
