Date: Sat, 22 Jun 2019 15:35:17 -0700 (PDT) From: Sean Eric Fagan <sef@kithrup.com> To: rmacklem@uoguelph.ca Cc: freebsd-fs@freebsd.org Subject: Re: RFC: What should a copy_file_range(2) syscall do by default? Message-ID: <20190622223517.6DF6514BC0@kithrup.com>
next in thread | raw e-mail | index | archive | help
>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 :).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190622223517.6DF6514BC0>