Re: [coreutils] cp --reflink

[Joel Becker]

On Mon, Mar 22, 2010 at 09:22:22PM +0100, Giuseppe Scrivano wrote:
> AFAICS, Btrfs does the same thing, copy-on-write on data extents; how
> does OCFS2 reflink differ (from an user point of view)?

        ocfs2's reflink (where the term was coined) is an atomic
creation of a new target inode duplicating the attributes of and sharing
cow data extents with the source.  btrfs's ioctl(2) links data extents
from one existing inode to another existing inode.  It is not atomic
regarding the target inode creation, and it doesn't inherently set the
attributes of the target inode.
        My original plan was to add reflink(2) with the behavior as
provided by ocfs2.  Chris had assured me that the btrfs internals
backing the data sharing ioctl(2) would allow btrfs to support
reflink(2) no problem.  So btrfs would honor reflink(2) just like ocfs2
would have.
        Two things happened.  First, Linus rejected reflink(2) and asked
for a more generic copyfile(2), which I haven't had time to flesh out.
So ocfs2 only supports reflink via OCFS2_IOC_REFLINK and btrfs not at
all.  Second, cp(1) added --reflink, but calling the btrfs ioctl(2), not
the reflink ioctl(2).
        I'll be getting to copyfile(2) eventually.  That will probably
be a whole new cp(1) argument set.  But what to do about "cp --reflink?"
The easiest answer is as Jeff suggests: teach it to call
OCFS2_IOC_REFLINK when the src and target are ocfs2.  This doesn't break
the btrfs usage and behaves as ocfs2 users expect.  It does, however,
leave the --reflink operation inconsistent.  I can't think of another
option that doesn't either divorce --reflink from OCFS2_IOC_REFLINK or
break the btrfs usage.

Joel

-- 

"I think it would be a good idea."  
        - Mahatma Ghandi, when asked what he thought of Western
          civilization

Joel Becker
Principal Software Developer
Oracle
E-mail: address@hidden
Phone: (650) 506-8127