[Bug 255523] vn_generic_copy_file_range copies holes to EOF slowly

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255523

            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 at FreeBSD.org
          Reporter: asomers at 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
==================
1) Mount a ZFS-backed file system using nfsv4 with minorversion=2
2) On the server, create a giant sparse file with "truncate -s 1t sparsefile"
3) On the client, copy it to local storage with "cp sparsefile /tmp"

Analysis
========

dtrace shows that vn_rdwr gets called repeatedly with len=64k.  Basically, it
extends the file by 64kB at a time.  That's due to the "xfer = blksize"
assignment in vn_generic_copy_file_range.  vn_generic_copy_file_range proceeds
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 handle
the hole efficiently.

-- 
You are receiving this mail because:
You are the assignee for the bug.