RFC: What should a copy_file_range(2) syscall do by default?
Sean Eric Fagan
sef at kithrup.com
Sat Jun 22 22:35:26 UTC 2019
>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 :).
More information about the freebsd-fs
mailing list