Date: Sat, 01 May 2021 22:48:59 +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-RAYzPIicJu@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 Rick Macklem <rmacklem@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #3 from Rick Macklem <rmacklem@FreeBSD.org> --- vn_generic_copy_file_range() was coded the way it is, since UFS (the only file system type I use/test on) always allocates a data block (all 0 bytes) at the end of the file. --> Never has a hole extending to EOF. I've attached a patch that tries to handle the hole to EOF case. Maybe you can test it? Btw, the data size in the copy loop is pegged at whatever the file system uses as a block size, capped at 1Mbyte. This implies that interrupting signals will be handled quickly. --> Recall that read(2)/write(2) ignore signals, except for the weird NFS "intr" mount option case. --=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-RAYzPIicJu>