Skip site navigation (1)Skip section navigation (2)
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>