Date: Sat, 01 May 2021 08:40:42 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 255523] vn_generic_copy_file_range copies holes to EOF slowly Message-ID: <bug-255523-227-ll6tWnf6zT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255523-227@https.bugs.freebsd.org/bugzilla/> References: <bug-255523-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255523 Mark Millard <marklmi26-fbsd@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #1 from Mark Millard <marklmi26-fbsd@yahoo.com> --- Would this deal with: https://cgit.freebsd.org/src/commit/?id=3D19fe23fa2bd52d6a42fb408d21b9d49c4= bee81ef Titled: "Make vn_generic_copy_file_range() interruptible via a signal." QUOTE This patch adds checks for signals that need to be processed after each successful data copy cycle. END QUOTE Might making the "data copy cycle" huge in some contexts reintroduce such problems by making the sig_intr() calls too infrequent? In other words: might vn_rdwr(. . .) and/or vn_write_outvp(. . .) sometimes take too long relative to checking sig_intr() frequently enough? There is also the cantseek related mem_iszero(dat,xfer) if xfer were huge. Note: I've not done a deep analyzis. I'm just asking based on what I see in the vn_generic_copy_file_range(. . .) code. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255523-227-ll6tWnf6zT>