On 2015-10-26 17:41, J. Bruce Fields wrote:
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.On Mon, Oct 26, 2015 at 12:19:33PM +0000, Pádraig Brady wrote: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.
If you want to make sure the space is allocated on disk, you should be using fallocate (or dd, or something equivalent), not cp.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
