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 -- 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
