Re: New reflink(2) syscall

[Theodore Tso <tytso@mit.edu>]

On Tue, May 05, 2009 at 10:13:31AM -0700, Joel Becker wrote:
> On Tue, May 05, 2009 at 12:56:58PM -0400, Chris Mason wrote:
> > On Tue, 2009-05-05 at 09:47 -0700, Joel Becker wrote:
> > > 	Because then you have to change the entire security structure,
> > > and you aren't a snapshot anymore.
> > 
> > I won't argue with the security part, but the snapshot part could just
> > as easily be defined by the data and not the inode.
> 
> 	In ZFS/btrfs/WAFL/disk array snaps, if you go back to a snap
> does the selinux context or acls or equivalent appear different?  I don't
> think so, and I expect people would be really upset if they had to know
> all the restorecon/acl-fu to get it right.

OK, now I understand; sorry, I didn't realize that when you said
"snapshot", what you were really talking about was a way to implement
WAFL-style snapshots, where reflink was a low-level operation that
would be used to implement that particular use case.  Hmm, maybe the
answer is that we implement reflinkat(2) with flags that indicate
whether this is supposed to be more like a hard link (i.e., acl and
ownership should be preserved) or more a like a copy (i.e., acl is
inherited from the new containing directory's directory creation acl,
uid/guid are set using the standard rules for creating new inodes).

Both use cases are equally valid, and I imagine there would be
interest in using reflinks both for snapshots and as a very
lightweight copy operation by commands like /bin/cp.

						- Ted