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

[Jamie Lokier <jamie@shareable.org>]

jim owens wrote:
> Jamie,
> 
> Joel Becker wrote:
> >	"Shares the data extents of the source file".
> 
> so with that clarification, do you now agree with this
> 
> > 1) is only for filesystems with COW operation,
> >    if the fs does not support COW it returns ENOSYS.
> 
> being a requirement so the user can trust that calling
> reflink() uses minimal space (inode/extentmap) and only

Yes I do, if

> a change to the file will trigger a data copy.

"file" means the data, not the permissions and timestamps :-)

Otherwise there's still a user trust issue, since many applications
come to mind who would like to chmod/chown/futimes immediately after
making the reflink, and they need to trust that the result uses
minimal space.

I realise now in the OCFS2/BTRFS cases this isn't an issue since
changing the data only unshares a small region of the data anyway.

But that's quite a difficult thing to ask of any filesystem which
implements reflink(), whereas saying "attribute changes do not trigger
COW" (well maybe chown/chgrp do) is reasonable for any filesystems
which can implement reflink().

-- Jamie