From nobody Sun Nov 09 07:14:01 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 4d43v76T1zz6GPXN for ; Sun, 09 Nov 2025 07:14:11 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [31.134.205.98]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d43v64Q1Fz3Gk2 for ; Sun, 09 Nov 2025 07:14:10 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=W1KsFt0Z; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 31.134.205.98 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws Received: from crmpreview1.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview1.colo2.realworks.nl (Postfix) with ESMTP id 09E9340147; Sun, 9 Nov 2025 08:14:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1762672442; 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; bh=cYROr2AXLrmZSBliZguFxPLJ9AosncXyPHHjhAwTnoU=; b=W1KsFt0Zbhw2aBTHsXRRHQ+cdMYibMZHdMrzqHjXtKLavMFh71prC+z0I/uKSzbqIimJje GD0hGpnUPMzjiuHJKDYpFrUmP4noTJQyYl1PZqNbzbENUIqyruWv0shNGoB+xhGi9XjJnb Uv1L/s1mVNgZUMxKfVFuSrQx+F1+4XJoz0AzW56mlAXsbvFHRaZXly6TdhJT13dTGpxKoR +o21CsrW2QFOHsl2c3f8UY0JrUizhGUrLCz2ZGCyN3q4drH6U2qFNr0GGvy270mvqFSXRf D8JvK2+ykV4ASRqffL3jH7UoHRu2ERvTXhHVVZ9raeavTtjiLpmUw0mg2LkzlQ== Date: Sun, 9 Nov 2025 08:14:01 +0100 (CET) From: Ronald Klop To: Rick Macklem Cc: Peter 'PMc' Much , FreeBSD CURRENT Message-ID: <2100145914.14642.1762672441817@localhost> In-Reply-To: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? 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: multipart/alternative; boundary="----=_Part_14641_1157727444.1762672441814" X-Mailer: Realworks (772.17) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:31.134.205.64/26]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4d43v64Q1Fz3Gk2 ------=_Part_14641_1157727444.1762672441814 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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? >=20 >=20 > Hi, >=20 > Peter Much reported a problem on the freebsd-fs@ mailing > list on Oct. 21 under the Subject: "Why does rangelock_enqueue() > hang for hours?". >=20 > 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. >=20 > 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. >=20 > Having a copy_file_range(2) syscall take two hours is > definitely an unusual case, but it does seem that it is > excessive? >=20 > 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. >=20 > 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 ??) >=20 > Note that the longer you allow copy_file_range(2) > to continue, the more efficient it will be. >=20 > Thanks in advance for any comments, rick >=20 >=20 >=20 >=20 >=20 Why is this locking needed? AFAIK Unix has advisory locking, so if you read a file somebody else is wri= ting the result is your own problem. It is up to the applications to adhere= to the locking. Is this a lock different than file locking from user space? Why can=E2=80=99t this tail a file that is being written by copy_file_range= if none of the applications request a lock? Regards, Ronald. ------=_Part_14641_1157727444.1762672441814 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: Rick Macklem &= lt;rick.macklem@gmail.com>
Datum: 9 november 2025 00= :23
Aan: FreeBSD CURRENT <freebsd-current@freebsd.or= g>
CC: Peter 'PMc' Much <pmc@citylink.dinoex.sub.= org>
Onderwerp: RFC: Should copy_file_range(2) retur= n 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 advisor= y locking, so if you read a file somebody else is writing the result is you= r own problem. It is up to the applications to adhere to the locking.
=
Is this a lock different than file locking from user space?
= Why can=E2=80=99t this tail a file that is being written by copy_file_range= if none of the applications request a lock?

Regar= ds,
Ronald.

------=_Part_14641_1157727444.1762672441814--