Re: RFC: multiple concurrent I/O ops for copy_file_range(2)

On Fri, Sep 2, 2022 at 9:11 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:
>
> Hi,
>
> A recent discussion involving copy_file_range(2) performance
> included a suggestion that, maybe, copying of subranges
> should be done concurrently.
>
> Although I cannot be 100% sure, I think that this would
> involve using multiple kernel threads (taskqueue or similar)
> to issue I/O operations on the file system(s) for blocks
> (of f_iosize maybe?) concurrently, to improve performance.
>
> Doing this in a system call is unusual, to say the least but, then,
> copy_file_range(2) is an unusual system call to begin with.
>
> I have not attempted to code this up as of yet.
>
> So, what do others think of this idea?
>
> rick

I'm skeptical.  Is the intention to speed up copying on file systems
that do or don't have an efficient VOP_COPY_FILE_RANGE implementation?
 For those that don't, I don't see any point in trying to beat the
speed of the old cp(1).  Apart from the problems that we've seen
around hole size, does the copy_file-range-enabled cp match the older
cp's performance?