On 2015-10-26 17:41, J. Bruce Fields wrote:

On Mon, Oct 26, 2015 at 12:19:33PM +0000, Pádraig Brady wrote:

quoted

I get the impression that you think reflinking should be hidden
from the user, i.e. cp(1) should not have had the --reflink option
(for the last 6 years)?  I'm not convinced of that, and even so
I think lower level interfaces would benefit from finer grained options.
This would be especially useful since there is no general interface
to reflink at present. I was happy with the reflink control options,
thinking the extra control could allow cp to use this by default.

Maybe that's a case for Christoph's "clone" operation.

I agree with him that it makes sense to allow the filesystem to
implement "copy" using reflink or similar tricks under the covers.  And
that in fact it's difficult to imagine how you'd prevent that in the
presence of layers of filesystem or block protocols underneath.

That "cp" flag seems strange to me, but if "cp" wants to take advantage
of a copy system call while continuing to make something like that
distinction then I suppose it could fallocate the destination range file
after the copy.

FWIW, I'm pretty sure that the '--reflink=never' option was added 
originally just for those poor misguided people who don't understand 
that deduplication is perfectly safe as long as you do it right. 
Personally, I really hope that Busybox and the other Coreutils 
replacements don't make that mistake, as the very fact that cp allows 
you to force it not to reflink things indirectly implies that it isn't 
safe in some circumstances, which is completely bogus WRT all the 
filesystems in Linux that support it if they are used properly.

If you want to make sure the space is allocated on disk, you should be 
using fallocate (or dd, or something equivalent), not cp.