coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 0/8] VFS: In-kernel copy system call


From: Darrick J. Wong
Subject: Re: [PATCH v1 0/8] VFS: In-kernel copy system call
Date: Wed, 9 Sep 2015 14:42:10 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Sep 09, 2015 at 04:41:34PM -0400, Anna Schumaker wrote:
> On 09/09/2015 04:38 PM, Chris Mason wrote:
> > On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote:
> >> On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason <address@hidden> wrote:
> >>> On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:
> >>>> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong <address@hidden> wrote:
> >>>>> On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:
> >>>>>> What I meant by this was: if you ask for "regular copy", you may end
> >>>>>> up with a reflink anyway.  Anyway, how can you reflink a range and
> >>>>>> have the contents *not* be the same?
> >>>>>
> >>>>> reflink forcibly remaps fd_dest's range to fd_src's range.  If they 
> >>>>> didn't
> >>>>> match before, they will afterwards.
> >>>>>
> >>>>> dedupe remaps fd_dest's range to fd_src's range only if they match, of 
> >>>>> course.
> >>>>>
> >>>>> Perhaps I should have said "...if the contents are the same before the 
> >>>>> call"?
> >>>>>
> >>>>
> >>>> Oh, I see.
> >>>>
> >>>> Can we have a clean way to figure out whether two file ranges are the
> >>>> same in a way that allows false negatives?  I.e. return 1 if the
> >>>> ranges are reflinks of each other and 0 if not?  Pretty please?  I've
> >>>> implemented that in the past on btrfs by syncing the ranges and then
> >>>> comparing FIEMAP output, but that's hideous.
> >>>
> >>> I'd almost rather have a separate call, maybe unshare_file_range()?
> >>>
> >>
> >> Doesn't it make more sense to put that functionality in fallocate()?

[slightly off-topic]

How about FALLOC_FL_UNSHARE_RANGE?  I've been looking for a place to land
an unshare op that isn't chattr +C, and fallocate seems like a better fit
anyway.

--D

> > 
> > That works too, I'm just hoping to keep the copy_file_range stuff
> > simple.
> 
> I agree with keeping copy_file_range() simple, especially for the initial
> merge.  Extra stuff can always be added in later :)
> 
> Anna
> 
> > 
> > -chris
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]