[Ocfs2-devel] [PATCH 1/3] fs: Document the reflink(2) system call.
Jamie Lokier
jamie at shareable.org
Tue May 5 16:12:10 PDT 2009
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
More information about the Ocfs2-devel
mailing list