[Ocfs2-devel] [PATCH 1/3] fs: Document the reflink(2) system call.

[Jamie Lokier <jamie@shareable.org>]

Theodore Tso wrote:
 But in that case, if in every user-visible sense of the
> word, it's equivalent to a file copy --- which is to say, it gets a
> new inode number, and, then why not make it work *exactly* like a file
> copy, which is to say make the ownership be the user who asked for the
> reflink to be created?  That way /bin/cp could potentially use
> reflinks, and aside from the fact that a cp -r of an existing
> directory hierarchy takes no extra disk space and runs *much* faster,
> a reflink acts exactly like a file copy.  The semantics are easy to
> describe, we don't need CAP_FOWNER nonsense, it becomes much easier to
> deal with the semantics vis-a-vis quota, etc.

reflink() seems to be designed to copy a file _and_ clone the file's
attributes exactly, and to do it all atomically.

So how about relaxing a bit and, since reflinkat() takes flags, giving
it a flag to make cloning the attributes optional.

I imagine there's little implementation difference between cloning the
attributes and giving it new file attributes, and both behaviours are
useful for different things.

-- Jamie