From nobody Mon Apr 10 18:31:21 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PwHcB10Htz44cMY; Mon, 10 Apr 2023 18:31:22 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PwHc973Xpz3sTd; Mon, 10 Apr 2023 18:31:21 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681151482; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fC1I7oT6LteSQYLER5bjeQ59ERotUQA7DafLOz3kW84=; b=rPlS3o3PcgR1GO8VnKEJ/2aw+O6o8ATVhyjPsR2VcVgxxi/J2gZ9RqGVDDYp4DYKsoJuh5 zPDsLqgQk/8P4hsYQx4vkWt1YHONKxzSKTz4Sx8GnAkbkLAvgoD+Atyc4UYOW0mJA1q8L8 QBIs+tJKqd1ModrIUuTWx5cMUigGKaDt71NKfOcg8vTdcigNtqzVxS3nNSAxjuG3BW5X0f 66hkchjGNd9HLOblWnOs1lL7Wqnu+WPARLt2ako+ejQ3kw52nraJbdbRw0Kg9Z9YOLFmRA uFVsMUlmIsXe+2SJqtGKC+CpN0uaaB1kFGZvNmb3HWLslWDYO21j4XGQTH5plw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681151482; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fC1I7oT6LteSQYLER5bjeQ59ERotUQA7DafLOz3kW84=; b=U6gojYX65T7w4IEFGkQnNm2y3SOj3GOwSh01r6SBfagWmy8V+7lYXZHuoPbmSJAa5p6SIp YM90ADoT6fLc3+/vwdBCUh2daheAygnVbwYE+JiTeOcsdW1cpnI54CPnDB39Iq+SOdiAy7 slR5PyoAcy73Uo93ennoP8Jd08LT8IHGXfDNmlSYPNaIo75X2QiCIhWSUCN6/b0OrrfOQR KvoecN0qVzkXvNb12PBYGJoHDdmNU/Hq6a3cfQHMSIQUahRY66AVimJFIRvZ6uKEcPPdZM vpjn1mGazCnXPla4q5uu4RTnCvBL4ABsz8C/pqhU+fT0gYV8xXv2fqQFDQEAXg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681151482; a=rsa-sha256; cv=none; b=M3yvjn37gtO4ZVFjOS62aTOLv5zSN0XvYyqfx2WYJlN3nsUgnHa6NihdBVz17x4dT3hJCx 9rU7u04BwCqv8dRvfKSQg6xa7PVo9hrwzSESk2TzstEZLXWMDmsOnXoQsPYCXFgoV000w4 nN9D5F/3x7hFBs1Vwgphm4J9FT6Gv1IBuEhN/haPPqom+7nKxigDGWl3l9qVcykefXp+tP Y/0+c/D98ETXQ8b590zmlWq6I/wpRs17vI76g1x4L+/NYxfAxEt0SO9VACdaXCcn26Zw9r udK925fXH7bjq+opSHhICAE2orucmGuwa5pLbBvXlgXsQiS9WOEACa38Auuw1A== Received: by freefall.freebsd.org (Postfix, from userid 1033) id D560219702; Mon, 10 Apr 2023 18:31:21 +0000 (UTC) Date: Mon, 10 Apr 2023 18:31:21 +0000 From: Alexey Dokuchaev To: Rick Macklem Cc: Rick Macklem , 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: References: <202101030102.10312IAC061762@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Mon, Apr 10, 2023 at 08:31:28AM -0700, Rick Macklem wrote: > On Mon, Apr 10, 2023 at 12:54???AM Alexey Dokuchaev wrote: > > 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 > > > > > > @@ -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 > > I think zfs_copy_file_range() needs to use vn_rlimit_fsizex() the > same way that vn_generic_copy_file_range() does. > > I have posted the attached patch to D39419. > > danfe@. Assuming you were using zfs, could you test this patch? > (You will need an up to date main kernel and, hopefully, the block > cloning stuff has not trashed your zpool.) We had already discussed with with Rick privately, but for the archives, looks like my problem had been solved somewhere between 13.1 and 13.2, and it's not related to ZFS. sh -c 'cd /tmp ; truncate -s 20m foo ; limits -f 8386560000 cp foo bar ; stat -f %z bar' ==> 13.1: Filesize limit exceeded 0 ==> 13.2: 20971520 Allegedly this is due to commit 52360ca, but I'd have to look closer into it to be sure. Sorry for distracting you guys from that recent ZoL merge fallout, I should've not be lazy and reported it earlier. :( ./danfe