Date: Sat, 01 May 2021 04:23:30 +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@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255523 Bug ID: 255523 Summary: vn_generic_copy_file_range copies holes to EOF slowly Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org vn_generic_copy_file_range can copy both data and holes. However, it copies holes much more slowly than theoretically possible. In my experiments using NFS 4.2 with FreeBSD 13.0-RELEASE servers and clients and ZFS local file systems, I can only achieve about 300 MBps when copying a file from NFS to local disk, when that file consists of a single giant hole. In theory, the maximum speed should be infinite, given a sufficiently "large" sparse file. Steps to Reproduce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) Mount a ZFS-backed file system using nfsv4 with minorversion=3D2 2) On the server, create a giant sparse file with "truncate -s 1t sparsefil= e" 3) On the client, copy it to local storage with "cp sparsefile /tmp" Analysis =3D=3D=3D=3D=3D=3D=3D=3D dtrace shows that vn_rdwr gets called repeatedly with len=3D64k. Basically= , it extends the file by 64kB at a time. That's due to the "xfer =3D blksize" assignment in vn_generic_copy_file_range. vn_generic_copy_file_range proce= eds to loop xfer bytes at a time. Instead, it should write the entire hole at once. Note that this only happens when the hole extends to EOF. If instead there= is a small data region at EOF, then vn_generic_copy_file_range does indeed han= dle the hole efficiently. --=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>