[Bug 252358] cp(1) of large files is causing 100% CPU utilization and poor transfer of ~168M/minute

[bugzilla-noreply at freebsd.org]

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

--- Comment #2 from commit-hook at FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=c98a764c681f8b70812a9f13a6e61c96aa1a69d2

commit c98a764c681f8b70812a9f13a6e61c96aa1a69d2
Author:     Rick Macklem <rmacklem at FreeBSD.org>
AuthorDate: 2021-01-03 00:58:43 +0000
Commit:     Rick Macklem <rmacklem at 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(-)

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