From nobody Mon Apr 10 07:54:49 2023 X-Original-To: dev-commits-src-main@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 4Pw1Tj6Vt7z44wFV; Mon, 10 Apr 2023 07:54:49 +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 4Pw1Tj5F4tz4P06; Mon, 10 Apr 2023 07:54:49 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681113289; 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=yQv6q5A3hDDb/jhrPj+MnQ+7f8LB7vPQZAr6DRloW/Q=; b=Z8Lu3qC1My1lb43JUH1qcEg3sysDjylL2N0Atlw+WjzkhdZA3v6TIaGpGJReqwGfZF09Et rZ9YFZmGypI6VUKg8je6e2WVZRcjDMDt1LCNw5CyRF90Nz9Y8VUleQsYwGbjOvjeWrD16L GSEXRItuEDpjaeyRExXL+Mw1Sqp6r5bjfSl+VRUfb0JUQlWXLtXrT//xys662Z2ZfMO7mv QgTtry6mSCOgFaOT9+qQkpgV9aig1jXDP/rsqHiAyIpmuPhh23xfUTYLsEomn08h6v+Aoj xb1Wb3Xv3ybpjaRSgXrtopvWhgqFBJ4Zg2sKwNEGJnqrlK4nhZpcNoq3mq+6EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681113289; 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=yQv6q5A3hDDb/jhrPj+MnQ+7f8LB7vPQZAr6DRloW/Q=; b=npR1Wow+EDjaDs2De8pISNa1Pq9tQ1EC2vQdulmRpeTu5TziUvwOEipiLlMgEAYMaLUJe7 mWzTJmINxESA0VCHQD8J2mkxLgi+5Pke6k+5JBmhdFPbgsgokK9VqAYUTtIqZFyr88CC1M VTdOqUXY59XSoq5CfiV5001bRzjE2rx7Yf4IQDWjsP2/0wek2bY8PePwkRiVzwEe+4tP8K rr14rO1FsuZ/ivBauKByV1A/JsioEVjxoTmRo+XU2gu1CqYhQD0NdnX2dG1v6CrUht80sy ypV905lsuQuI1UTDy7w8Wu8KQ/mkiFHCP83f273anwwfs44UPffVOs4VrfLP3A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681113289; a=rsa-sha256; cv=none; b=GXC0Y152QRb7igXSH6moKSSDprh0ZRQ7YMXywFmGIJ/JGEjBl9UYk7iv6lFogEMpDQA4on h26Sea291hFHKWfnZuLb5kRlC6nYV7Qbr7IiyhDqwVBZv+z4LAr4431q9EbaRevRYx7fu1 IWhASFRvtn4cpyPAFfVcP77ZevToDa+GtfbREFMwYJzHpnSDh9b3SEKCoUkA5qHCUAHyoP BlqeJei9xkxZOp6K96SddUtcJkCkZkrjef1v4EWyrBb1AKDBwSlqzOjr+D/xocC+UZ6ukx 7ttlUABdm9nzbBCFnXPRsLvPofvdkb5aKwdIwlPGdbUrc8mRf2WmMuw4A97lcw== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 9EC80621; Mon, 10 Apr 2023 07:54:49 +0000 (UTC) Date: Mon, 10 Apr 2023 07:54:49 +0000 From: Alexey Dokuchaev To: Rick Macklem 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: References: <202101030102.10312IAC061762@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202101030102.10312IAC061762@gitrepo.freebsd.org> X-ThisMailContainsUnwantedMimeParts: N 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