From nobody Mon Nov 10 08:58:17 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 4d4k945Tbzz6GQSl for ; Mon, 10 Nov 2025 08:58:32 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d4k940DVHz3CKR for ; Mon, 10 Nov 2025 08:58:32 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay.org header.s=google header.b=K62xd89D; dmarc=pass (policy=quarantine) header.from=iitbombay.org; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=bakul@iitbombay.org Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-3437ef3c9a4so93314a91.3 for ; Mon, 10 Nov 2025 00:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay.org; s=google; t=1762765109; x=1763369909; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1fGSm5tcZd22Nf+X2PXaEOlLHTqXgurgoWLhqLdnX/0=; b=K62xd89Dt0zb8Pk4OWzmODxO6FMOuUSUvKA4hV/28TPRahO8n2zDAlEOIXahOIB6Kw UIXcZS8sdwxC2spg6vPR5Yia2gMClwlV1z0uCQSw+EumvCPmMx3eInLWjmcTqfV31MwE +anBhHqO/vIZwfT/BPEPAyb/V7JwOqfttyBI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762765109; x=1763369909; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1fGSm5tcZd22Nf+X2PXaEOlLHTqXgurgoWLhqLdnX/0=; b=R0f/1JTHYt+6AEDVO6FydQ2fGFWcmFMrXHzf9xqgOdBBgSQgWTZsPQ7ECBh3ZvmwDY zML1fkta0QEAUzedJFtHoZrZZyOJbiT2a5uSA607a0XXOibekJGKuiehqzTKxHD518ON TNJFbygbfv0BdOHnjBXMptl0aDw8SQJHJpdnH9bSBqV+uoE77F4It4KmBxJmbjOR48fK lJ5t6yZJvBvjPINr715R1U4cuAaAlqx51enQDW0EJA9AdyOVEnHTaDYS4dCpT+Rdn5U0 AbVuCz83OOzpiC98QARvOmeVau7B+c0OYYFhixs5jNjYtAW+bwR/Scjyuz2BfkitEYY8 yAXA== X-Forwarded-Encrypted: i=1; AJvYcCVdCDoGIDEJ5ypLwDX16CX+fa8d6DfdmFGWjL+Lu6qWYNNh4vAejHb/9mr7wSCqlDJKY8ZF8RTBPdcPRLUgaRU=@freebsd.org X-Gm-Message-State: AOJu0YwI0I1xllob8brc01lIYSF4yBhuSAwcueJo6NWvkE9fSTNNsDYU j948puR8KBot4qA+JPcOK6NOtdAa81K6OncTFFXpNi+HKbzx6iMIVRo6iajuseRk0w== X-Gm-Gg: ASbGnctIu+EHSiA8OxokZZywVhRGlwFBJ+G6ba7EMi7b5XKUfH46iJ8MUyDhQgZr/Lo w5AMyYlx6AsM8QEUBLqqw29YkhCJ/uXfJ6rVXQcX2kDsSvthM8VFXUmYSkcAghU7n5zFfj8M6tB /+VcbaHcBs1FDTyelPkM8rRkRn+EAurJav5FFk4ENgSX0dtOFH5OC6uoFtx1r3cYdWY3GO6bSCl kwhK+gC1WnJEP9XN2HhbcgpLIK61RDZB947qeUG8CmxOYdS3JGlVLFLSAjJtoDa5eSN9q9u/wpm yA/mirfTZGUwYXszUzhLQMeuO9gLR5+287lA71ze7SA++HXkYc3polVsWnsa1svM7DkOauT7UcF U57JJtZagVsk4UmaB5cvTT4nbr9pOGt9PX2809HFkcu7njUcLaVUq0WH780PL0Azowuw7ZU+miR XnS4fcaNFhd+VLNYo9y+f0htc2Xohxjl0r+fRe1rrHtKGW6bYInpqPPGcYtkiWfDf/eWIlhAFeL zMYp7pzpgfbfRI/ X-Google-Smtp-Source: AGHT+IEQGa1V/2Ebd1ExBsdQrVrA9ZtxQuhoqUirKiUlF/UolHiheZsSM1QK+v/oRc4vQc0ybsopGA== X-Received: by 2002:a17:90b:1b44:b0:341:88bc:7a54 with SMTP id 98e67ed59e1d1-3436ccf5f21mr5121905a91.7.1762765109571; Mon, 10 Nov 2025 00:58:29 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-ba8ffe36bbasm11830280a12.18.2025.11.10.00.58.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2025 00:58:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3864.200.81.1.6\)) Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? From: Bakul Shah In-Reply-To: Date: Mon, 10 Nov 2025 00:58:17 -0800 Cc: Ronald Klop , Peter 'PMc' Much , FreeBSD CURRENT Content-Transfer-Encoding: quoted-printable Message-Id: References: <2100145914.14642.1762672441817@localhost> To: Rick Macklem X-Mailer: Apple Mail (2.3864.200.81.1.6) X-Spamd-Bar: / X-Spamd-Result: default: False [-1.00 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[iitbombay.org,quarantine]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[iitbombay.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[iitbombay.org:+]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[bakul]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102b:from] X-Rspamd-Queue-Id: 4d4k940DVHz3CKR On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem = wrote: >=20 > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop = wrote: >>=20 >> 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 adhere 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/004704.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.) Traditionally reads/writes on Unix were atomic but that is not the case for NFS, right? That is, while I am reading a file over NFS someone else can modify it from another host (if they have write permission). That is, AFAIK, the POSIX atomicity requirement for ead / write is broken by NFS except for another reader/writer on the same host. Another issue is that a kernel lock that is held for a very very long time is asking for trouble. Ideally one spends as little time as possible in the supervisor state and any optimization hacks that push logic into the kernel should strive to not hold locks for very long so that things don't grind to a complete halt. That is, copy_file_range() use in cat(1) seems excessive. The only reason for its use seems to be for improving performance. Why not break it up in smaller chunks? That way you still get the benefit of reducing syscall overhead (which pales in comparision to any network reads in any case) + the same skipping over holes. Small reads/wries is what we did before this syscall raised its head!=