[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 0/8] VFS: In-kernel copy system call
From: |
Andy Lutomirski |
Subject: |
Re: [PATCH v1 0/8] VFS: In-kernel copy system call |
Date: |
Wed, 9 Sep 2015 13:37:44 -0700 |
On Wed, Sep 9, 2015 at 1: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()?
>
> Is that the end goal to the sharing check?
My use case was archival. I can reflink data between a working copy
and some archived copy and then I can very efficiently tell if the
working copy has been changed by checking if the reflink is still
linked.
It would be even better if I could enumerate which parts of one file
match which parts of another file.
--Andy
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, (continued)
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Darrick J. Wong, 2015/09/08
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Andy Lutomirski, 2015/09/08
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Darrick J. Wong, 2015/09/08
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Andy Lutomirski, 2015/09/08
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Darrick J. Wong, 2015/09/08
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Chris Mason, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Trond Myklebust, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Chris Mason, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Anna Schumaker, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Darrick J. Wong, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call,
Andy Lutomirski <=
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Chris Mason, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Dave Chinner, 2015/09/13
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Andy Lutomirski, 2015/09/14
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Anna Schumaker, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Darrick J. Wong, 2015/09/09
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Anna Schumaker, 2015/09/10
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Austin S Hemmelgarn, 2015/09/10
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Austin S Hemmelgarn, 2015/09/10