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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
