On 2015-10-14 14:27, Christoph Hellwig wrote:
> 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.
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).

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