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: [email protected]
Reporter: [email protected]
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
