Date: Mon, 10 Apr 2023 07:54:49 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Rick Macklem <rmacklem@freebsd.org> Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: c98a764c681f - main - cp(1): fix performance issue for large non-sparse file copies Message-ID: <ZDPAyZiFtkJv79oF@FreeBSD.org> In-Reply-To: <202101030102.10312IAC061762@gitrepo.freebsd.org> References: <202101030102.10312IAC061762@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 03, 2021 at 01:02:18AM +0000, Rick Macklem wrote:
> commit c98a764c681f8b70812a9f13a6e61c96aa1a69d2
>
> 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.
> char *p;
>
> @@ -236,7 +235,7 @@ copy_file(const FTSENT *entp, int dne)
> do {
> if (use_copy_file_range) {
> rcount = copy_file_range(from_fd, NULL,
> - to_fd, NULL, bufsize, 0);
> + to_fd, NULL, SSIZE_MAX, 0);
Hi Rick,
This change unfortunately breaks copying files in resource-limited
environments (e.g. many port builders do that to prevent runaway
processes):
ulimit -f 16384000
cp -p packages/13.0-i386-wip/All/perl5-5.32.1_3.tbz /tmp ; echo $?
Filesize limit exceeded
153
Previously bufsize was 2097152 which was a lot saner than current
9223372036854775807. Perhaps we should set it per getrlimit(2)
value for RLIMIT_FSIZE?
./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZDPAyZiFtkJv79oF>