RFC: What should a copy_file_range(2) syscall do by default?

[Sean Eric Fagan]

>Well, all I am interested in is a system call/VOP call so the NFSv4.2
>client can do
>a file copy locally on the NFS server instead of doing Reads/Writes
>across the wire.
>The current code has gotten fairly complex, so I'll try and ask "how
>complex" this
>syscall/VOP call should be?

In a previous life, I was responsible for one of the file copy libraries, so
this is something I do have experience with.  (I find the copy-range syscall
interesting; AFP had a command to copy an entire hierachy on the server.)

>       --> The Linux man page mentions using copy_file_range(2) in a loop with
>             lseek(SEEK_DATA)/lseek(SEEK_HOLE) for sparse files. This
>suggests that
>             the Linux fallback code doesn't try to handle holes.

As far as I can tell, correct; instead, the copy routine looks for holes in
user space, and copies the non-holes.

>Linux discussions have talked about improved performance for local file systems
>based on reduced # of system calls, but I have not seen any data to show what,
>if any, performance improvement has been observed. (The slow hardware I have
>to test on won't be useful for performance evaluation.)

My experience shows that it's minimal, if all it will be copying is a single
file.  There would have to be a lot of system calls, and a *lot* of syscall
overhead, for that to hold sway -- and they're also doing the checks for
holes, which may end up increasing the number of system calls for them by a
significant amount.  I'm still skeptical.

Alan mentioned locking, which does buy you something, but it also means
*locking the file while it is being copied*.  Which, for large files, is not
so great.  I also don't think you can call any large copy atomic, unless
you're using a signle transaction for the entire copy.

Anyway:  I don't have a big objection to it, other than putting a lot of work
into a system call, but as I said I'm clearly a couple decades behind on that
sentiment :).