On 2015-10-14 14:27, Christoph Hellwig wrote:
Whether or not reflink is different from a copy is entirely a matter of who is looking at it. For someone looking directly at the block device, or trying to manipulate the block layout of the filesystem it is definitely not a copy. For a database app that needs ACID transaction semantics, it is definitely not a copy (although for that usage, it's arguably significantly better than a copy). From the point of view of a generic userspace app that didn't perform the copy operation however, and for anyone looking at it after the fact without paying attention to the block layout, a reflink _is_ for all intents and purposes functionally equivalent to a copy of the reflinked data (assuming of course that the filesystem implements it properly, and that the hardware behaves right).On Wed, Oct 14, 2015 at 11:08:40AM -0700, Andy Lutomirski wrote:So what I'm hearing is that I should drop the reflink and dedup flags and change this system call only perform a full copy (with preserving of sparseness), correct? I can make those changes, but only if everybody is in agreement that it's the best way forward.I personally rather like the reflink option. That thing is quite useful.reflink is very useful, probably more useful than the copy actually. But it is different from a copy. It should be a separate interface.
I would not in fact be surprised if at least some SCSI devices that implement the XCOPY command do so internally using a reflink (I have not personally read the standard, but even if it 'requires' a compliant device to actually create a separate copy of the data, there will still be some vendors who ignore this), and it is well known that some SSD's do in-band data deduplication effectively reducing a traditional copy to a reflink at the firmware level.
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'.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
