Re: [PATCH 3/3] ovl: Use splice_with_holes in copy_up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux