On Wed, Sep 09, 2015 at 01:37:44PM -0700, Andy Lutomirski wrote: > On Wed, Sep 9, 2015 at 1:09 PM, Chris Mason <clm@xxxxxx> 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 <darrick.wong@xxxxxxxxxx> 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. Oh ok, we can do that pretty quickly with the btrfs searching ioctl (just walk the items, really fast), but that's root only. For a real interface maybe a btrfs specific ioctl to compare file ranges. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
