[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 0/8] VFS: In-kernel copy system call
From: |
Anna Schumaker |
Subject: |
Re: [PATCH v1 0/8] VFS: In-kernel copy system call |
Date: |
Wed, 9 Sep 2015 16:41:34 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
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()?
>
> 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
>
- Re: [PATCH v3 8/9] VFS: In-kernel copy system call, (continued)
- Re: [PATCH v3 8/9] VFS: In-kernel copy system call, Pádraig Brady, 2015/09/29
- Re: [PATCH v1 0/8] VFS: In-kernel copy system call, Pádraig Brady, 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, 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 <=
- 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, 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, 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