From owner-freebsd-fs@freebsd.org Sat Jun 22 22:35:26 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23D9715BB932 for ; Sat, 22 Jun 2019 22:35:26 +0000 (UTC) (envelope-from sef@kithrup.com) Received: from kithrup.com (kithrup.com [96.79.110.97]) by mx1.freebsd.org (Postfix) with ESMTP id 478F78FF58 for ; Sat, 22 Jun 2019 22:35:24 +0000 (UTC) (envelope-from sef@kithrup.com) Received: by kithrup.com (Postfix, from userid 1001) id 6DF6514BC0; Sat, 22 Jun 2019 15:35:17 -0700 (PDT) To: rmacklem@uoguelph.ca Subject: Re: RFC: What should a copy_file_range(2) syscall do by default? Cc: freebsd-fs@freebsd.org Message-Id: <20190622223517.6DF6514BC0@kithrup.com> Date: Sat, 22 Jun 2019 15:35:17 -0700 (PDT) From: Sean Eric Fagan X-Rspamd-Queue-Id: 478F78FF58 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of sef@kithrup.com designates 96.79.110.97 as permitted sender) smtp.mailfrom=sef@kithrup.com X-Spamd-Result: default: False [-3.46 / 15.00]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[kithrup.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[earth.kithrup.com,kithrup.com,backup-1.kithrup.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; IP_SCORE(-2.26)[ip: (-7.62), ipnet: 96.64.0.0/11(-3.65), asn: 7922(0.03), country: US(-0.06)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 22:35:26 -0000 >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 :).