On Wed, Oct 14, 2015 at 03:08:46PM -0400, Austin S Hemmelgarn wrote: > Whether or not reflink is different from a copy is entirely a matter of who > is looking at it. So what? I've been trying to explain why clone semantics matter, and I've not seen a counter argument for that. I've also explained a couple times that a valid clone always is a valid copy, and I've only heard some slight disagreement, and so far none as long as we take the COPY_FALLOCATE option into account. Note that all of this also applies to storage devices - any smart array will do a clone-like operation underneath an XCOPY, but so far SCSI doesn't provide full clone _semantics_ even if you can emulate a lot of it using a lot of complexity around ROD tokens. Similar at the SCSI level you can perform a fallocate-like operation using the anchor bit in the UNMAP or WRITE SAME commands. > I agree that we shouldn't try to make a reflink by default (less than > intelligent programmers won't read the docs completely, and will make > various stupid assumptions about how this is 'supposed' to work, making the > defaults less ambiguous is a good thing), but it makes sense (at least, it > does to me) to have the ability to say 'make this block of data appear at > this location as well, I don't care how you do it as long as they are > functionally independent for userspace applications'. Yes, we absolutely should use reflink as a default implementation for copy where available. But we also need a clone or reflink interface that only gives us well specified reflink semantics, and not the much weaker copy semantics. -- 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
