Date: Sat, 22 Jun 2019 23:10:20 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Sean Eric Fagan <sef@kithrup.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: RFC: What should a copy_file_range(2) syscall do by default? Message-ID: <YQXPR01MB0278E2A294105A8E0C2E15A7DDE60@YQXPR01MB0278.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20190622223517.6DF6514BC0@kithrup.com> References: <20190622223517.6DF6514BC0@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Eric Fagan wrote: >>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 sysca= ll >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 i= n >user space, and copies the non-holes. For NFSv4.2, the client can do SEEK_DATA/SEEK_HOLE against the server, alth= ough it does imply extra RPC RTTs. >>Linux discussions have talked about improved performance for local file s= ystems >>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 h= ave >>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 sing= le >file. There would have to be a lot of system calls, and a *lot* of syscal= l >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. Yes, my hunch is the same. However, I do expect a performance improvement for NFS (at least for large = files), due to savings w.r.t. RPC RTTs and avoiding data going server->client->serv= er. I suspect avoiding the kernel/userspace transitions may help w.r.t. fuse, t= oo. >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 n= ot >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. I tried posting w.r.t. atomicity and didn't get a lot of responses. However= , although kib@ didn't exactly say it should be the case, he did point out that FreeBS= D has traditionally ensured atomicity of file updates for syscalls and felt that = was a good thing. As such, I've done the range locking of both files and created new p= rimitives to do that while avoiding deadlock. If others have opinions w.r.t. atomicity of file data updates within this s= yscall, please post to either that thread or this one. >Anyway: I don't have a big objection to it, other than putting a lot of w= ork >into a system call, but as I said I'm clearly a couple decades behind on t= hat >sentiment :). Thanks for your comments. However, you didn't seem to indicate your preferr= ed alternative? I, personally, don't care, but would like to find out what the "collective"= thinks, rick.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR01MB0278E2A294105A8E0C2E15A7DDE60>