Theodore Tso wrote: But in that case, if in every user-visible sense of the > word, it's equivalent to a file copy --- which is to say, it gets a > new inode number, and, then why not make it work *exactly* like a file > copy, which is to say make the ownership be the user who asked for the > reflink to be created? That way /bin/cp could potentially use > reflinks, and aside from the fact that a cp -r of an existing > directory hierarchy takes no extra disk space and runs *much* faster, > a reflink acts exactly like a file copy. The semantics are easy to > describe, we don't need CAP_FOWNER nonsense, it becomes much easier to > deal with the semantics vis-a-vis quota, etc. reflink() seems to be designed to copy a file _and_ clone the file's attributes exactly, and to do it all atomically. So how about relaxing a bit and, since reflinkat() takes flags, giving it a flag to make cloning the attributes optional. I imagine there's little implementation difference between cloning the attributes and giving it new file attributes, and both behaviours are useful for different things. -- Jamie -- 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
