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/
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
