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

Alan Somers <asomers@freebsd.org> wrote:
>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?
I suppose so. In particular, when the input and output files are on
different file systems, a custom VOP_COPY_FILE_RANGE() cannot be used.

> 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?

Well, the discussion starts here:
https://lists.freebsd.org/archives/dev-commits-src-main/2022-August/009067.html
For some reason, there seems to be missing entries. I recall replying
to the one that suggested concurrent I/O operations (by mav@, I think?)
that I would post here asking about it. (I've cc'd mav@, in case he wishes
to comment further.)

I do agree that doing some performance evaluation of cp(1) would be
useful.
--> The thread seemed to suggest (I'm no ZFS guy) that mmap'd
      copying does not help for ZFS and that doing copy_file_range(2)
      for small files instead of the mmap'd copying might make sense.
--> Then there was mention of having copy_file_range(2) do concurrent
      copying of blocks, which precipitated the email.

rick