Re: [PATCH 4/8] add copy_file_range syscall support

[David Disseldorp]

Hi Luis,

On Sat, 20 Mar 2021 01:00:45 +0100, David Disseldorp wrote:

> > As I've already told you somewhere else, copy_file_range (crf for short!)
> > implementations may expand any existing holes in the original file.
> > That's OK, I guess, but it may be worth adding a comment here and possibly
> > on the cpio(1) manpage, when documenting the --reflink option.
> > 
> > Another option would be to add a bit more complexity here by calling crf
> > in a loop and lseek'ing SEEK_DATA/SEEK_HOLE.  That's what my original RFC
> > patch was doing, but I agree that it's probably not worth it.
> > 
> > My suggestion is to, at least, add here a small comment mentioning this
> > decision and referring to the cfr manpage for the details.  
> 
> It's still a little unclear to me under what condition hole expansion
> can occur (splice only, or also in some reflink cases, etc.). I'll add
> back the SEEK_DATA / SEEK_HOLE logic that you had, as it should at least
> speed up processing of Dracut padding entries.

As mentioned in the v2 patchset description:
  + I decided against adding back SEEK_DATA / SEEK_HOLE functionality to
    the copy_files_range loop, as seek cursor tracking and error
    handling add significant complexity with little benefit to my
    initramfs generation workload

I've attached the RFC patch (applies atop V2) that I have for it, just
in case you're curious how ugly it gets ;-)

Cheers, David

0001-RFC-SQUASH-seek-past-holes-in-copy_file_range-loop.patch
Description: Text Data