From nobody Mon Nov 10 08:15:44 2025 X-Original-To: freebsd-current@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 4d4jCl3yJXz6GN5Z for ; Mon, 10 Nov 2025 08:15:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d4jCl3QkPz4540; Mon, 10 Nov 2025 08:15:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762762547; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C0x0i192eji2bNK2symwzhI5LRGB1wyHZYQRBBZe2yI=; b=nBk4UgwQdXVD/6vOg7qrxLxxGReNL8VWfDTKNQqv/dCiHGgnxy+90w1mS13I5rlDpORide MLi2niUwUJVBIim4zhe7rqqGrXtDsDgnOr6rfSR1Tz77PDXzGH6BTn6X1CTyKiAyeVPuWT +d3weAIyLxVhTYw35ICAAHzS7zrs48hwRIxUswsVMnpmbvTXm4qFHX1ThqwHUUoVrUMT4y wvxISKW6hnsCKbh6gP2QoPzf7YLLVxfVvdYEM7rjuczb/G401R6JoaK4UudSYy5jFhNaiz yBtCXHYI5ouhdZJA1KF3QqgBvEzWpSsZmTEWe69VIA3CZnU0Nl4VAfsTMpWEOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762762547; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C0x0i192eji2bNK2symwzhI5LRGB1wyHZYQRBBZe2yI=; b=jZy7y02ferd96exSarEXuaJ9gIwcvhD3Bycd0ruaqH2157sZ/YCvurbeIK8My9MMAx0UKo 6kHvzcrwMRn0i57JCpi4WJbuDUTP3XcF4bK0+Rp+4FdGt47T6CQjhJDEQYX+vqxXo1/mox miwRPvvrWnNcNU4ul0H0fBntqERkJlMOSqqROcuqN2O9mEyz03b/CC0GehAuWveOWIvS/F jaAx3HmypCqGqDesO+ffIiXdm31xLDqq3n26mg4Mo/Bc4G+gldc5YPyKScQWtox0m8kQMU 6UZI0fguI5IHcbpNcE4T0Ma6OzLgkP2BBzQG4+mGyoVwPX7jiyLxRGoXW7v0rw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762762547; a=rsa-sha256; cv=none; b=SAlpc2pgK8uUy7//0kiE+3B1FG7rdL896/5d0rX4flgOXx3QvNQtPlO+RaI1s+YLBpFCAQ 3N6OXZIBAILDdkk/0uhdusI+SbUwAUn1KYYWmA+Oy+9rlNEiSsIU6pLLbvKe5PAZkidb8a KJu0SyRGu+VUgaLrEHknmjaCILedsUH/oDQAArAA+9sRLgpE8Tfsb/e7oZUMHM54ODLHgV PreksbFtmugr2I6Cogp6DDzWZ5fFXya1l3U00EZYUudhW4FFxn25cjKJUu5NdTlTwxJZdY eWwkfrQROEx1jyWKOPbpeYiONxVDfnGDpEeODZdAAdwLwuYLJooovaXOXlI9EA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d4jCk5Bn6zlZq; Mon, 10 Nov 2025 08:15:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Mon, 10 Nov 2025 00:15:44 -0800 (PST) From: Don Lewis Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Rick Macklem cc: Ronald Klop , Peter 'PMc' Much , FreeBSD CURRENT In-Reply-To: Message-ID: References: <2100145914.14642.1762672441817@localhost> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE On 9 Nov, Rick Macklem wrote: > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: >> >> >> Van: Rick Macklem >> Datum: 9 november 2025 00:23 >> Aan: FreeBSD CURRENT >> CC: Peter 'PMc' Much >> Onderwerp: RFC: Should copy_file_range(2) return after a few seconds? >> >> Hi, >> >> Peter Much reported a problem on the freebsd-fs@ mailing >> list on Oct. 21 under the Subject: "Why does rangelock_enqueue() >> hang for hours?". >> >> The problem was that he had a copy_file_range(2) copying >> between a large NFS file and a local file that was taking 2hrs. >> While this copy_file_range(2) was in progress, it was holding >> a rangelock for the entire output file, causing another process >> trying to read the output file to hang, waiting for the rangelock. >> >> Since copy_file_range(2) is not any standard (just trying to >> emulate the Linux one), there is no definitive answer w.r.t. >> should it hold rangelocks. However, that is how it is currently >> coded and I, personally, think it is appropriate to do so. >> >> Having a copy_file_range(2) syscall take two hours is >> definitely an unusual case, but it does seem that it is >> excessive? >> >> Peter tried a quick patch I gave him that limited the >> copy_file_range(2) to 1sec and it fixed the problem >> he was observing. >> >> Which brings me to the question... >> Should copy_file_range(2) be time limited? >> And, if the answer to this is "yes", how long do >> you think the time limit should be? >> (1sec, 2-5sec or ??) >> >> Note that the longer you allow copy_file_range(2) >> to continue, the more efficient it will be. >> >> Thanks in advance for any comments, rick >> >> ________________________________ >> >> >> >> Why is this locking needed? >> AFAIK Unix has advisory locking, so if you read a file somebody else is = writing the result is your own problem. It is up to the applications to adh= ere to the locking. >> Is this a lock different than file locking from user space? > Yes. A rangelock is used for a byte range during a read(2) or > write(2) to ensure that they are serialized. This is a POSIX > requirement. (See this post by kib@ in the original email > discussion. https://lists.freebsd.org/archives/freebsd-fs/2025-October/00= 4704.html) >=20 > Since there is no POSIX standard for copy_file_range(), it could > be argued that range locking isn't required for copy_file_range(), > but that makes it inconsistent with read(2)/write(2) behaviour. > (I, personally, am more comfortable with a return after N sec > than removing the range locking, but that's just my opinion.) >=20 > rick >=20 >> Why can=E2=80=99t this tail a file that is being written by copy_file_ra= nge if none of the applications request a lock? Since writes don't go backwards, it would seem to make sense to advance the start of the range lock as the copy proceeds. As long as the read position + length is before the write position, there is no reason to block the read. Running "cat outfile" would look a lot like tail -f because cat would only see the new data because it would temporarily block if it ever caught up with the copy. tail is a bit funky, though. If the size of the destination file is updated periodically during the copy, tail could return early with an earlier part of the file. If the size is updated immediately to the final size, then tail will wait for the copy to complete, but will output the true end of the file. What about backups?