Re: [PATCH v1 0/8] VFS: In-kernel copy system call
From: Andy Lutomirski <hidden>
Date: 2015-09-09 20:37:44
Also in:
linux-btrfs, linux-fsdevel, linux-nfs
On Wed, Sep 9, 2015 at 1:09 PM, Chris Mason [off-list ref] wrote:
On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote:quoted
On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong [off-list ref] wrote:quoted
On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote:quoted
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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html