Date: Sun, 03 Jan 2021 01:02:20 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252358] cp(1) of large files is causing 100% CPU utilization and poor transfer of ~168M/minute Message-ID: <bug-252358-227-FRIxh4W9uj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-252358-227@https.bugs.freebsd.org/bugzilla/> References: <bug-252358-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=3D252358 --- Comment #2 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dc98a764c681f8b70812a9f13a6e61c96a= a1a69d2 commit c98a764c681f8b70812a9f13a6e61c96aa1a69d2 Author: Rick Macklem <rmacklem@FreeBSD.org> AuthorDate: 2021-01-03 00:58:43 +0000 Commit: Rick Macklem <rmacklem@FreeBSD.org> CommitDate: 2021-01-03 00:58:43 +0000 cp(1): fix performance issue for large non-sparse file copies PR252358 reported a serious performance problem when copying a large non-sparse file on a UFS file system. This problem seems to have been caused by a large number of SEEK_HOLE operations, with one done for each copy_file_range(2) call. This patch modifies cp(1) to use a large (SSIZE_MAX) len argument, reducing the number of system calls and resolving the performance issue. While here, convert the type of the "rcount" from "int" to "ssize_t" so that it is consistent with that returned by both read(2) and copy_file_range(2). PR: 252358 Reviewed by: asomers Differential Revision: https://reviews.freebsd.org/D27937 bin/cp/utils.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) --=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-252358-227-FRIxh4W9uj>