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

[jim owens <jowens@hp.com>]

So summarizing the main argument of the day,
there are 2 different functions proposed:

1) "snapfile" - Joel's reflink(2) design.

The definition is good.  It makes writable snapshots
possible, and is security safe with CAP_FOWNER added
as a requirement because CAP_CHOWN is very restricted
in the real world.  Only the owner and admin can reflink.
For the admin to use it in backups, it must be a single
call as Joel said, a point in time of data and attributes.

If the name "reflink" is the problem, call it something else.

2) "cowfilecopy" - Ted's/Jamie's kernel cp.

Again, the definition makes sense.  The security model
is simply "current read access to the file", so anyone
who can read it can make almost-zero-space-consumed copy
of a file.

--- analysis ---

You ask why not use a 2-step "cowfilecopy" and "attrfilecopy"
to do "snapfile"... because that is not an atomic snapshot.

The security and "might not know about it" concerns are bogus:
No extra visibility exists to future updates of the original
file that would not exist without either snapfile or cowfilecopy.
That BOTH point at your old data is no different than if root
or raid was copying every disk block to permanent storage. If
you write it, someone can have it later.

So bottom line... I see no reason (except someone has to document)
why we should not have 2 system calls since there are good uses
and good definitions for both and the code is 99% identical.

jim