On May 5, 2018, at 5:16 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Thu, May 03, 2018 at 08:29:36PM -0500, Goldwyn Rodrigues wrote: >> >> On 05/03/2018 05:11 PM, Dave Chinner wrote: >>> >>> Yup, we want the copy offload infrastructure to be used if at all >>> possible, so we get consistent behaviour for everyone trying to >>> optimise copy behaviour. In this case, I think that it is relevant >>> that we heard at LSFMM that userspace utils don't want to use >>> copy_file_range() because it doesn't "optimise for sparse files". >>> >>> From that perspective, perhaps this needs "hole preserving copy" >>> behaviour needs to be moved inside copy-file_range() (and therefore >>> do_splice_direct()) and triggered by a new flag for >>> copy_file_range(). e.g. COPY_FILE_SPARSE. That way callers can tell >>> the kernel they want a sparse copy, and the kernel can attempt that >>> rather a copy that converts holes to zeros. >> >> In the patchset description [0], I ask if this should be the default >> feature (I think it should be) and holes should be converted to zeros as >> a special flag.. The only argument against it could be that applications >> are already using this interface, so this would be a change in behavior. > > In general, we don't change the behaviour of syscalls after the > fact. We have flags to control behaviour, so applications that want > to preserve holes will just have to be changed to use that flag. It's hard to think of a normal use case where someone created a file with holes, but wants the holes to be filled in when the file is copied... The "cp" utility defaults to "--sparse=auto", but allows "--sparse=never" to force hole filling, so it makes sense to handle the in-kernel copy the same way. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
