Date: Mon, 10 Nov 2025 00:58:17 -0800 From: Bakul Shah <bakul@iitbombay.org> To: Rick Macklem <rick.macklem@gmail.com> Cc: Ronald Klop <ronald-lists@klop.ws>, Peter 'PMc' Much <pmc@citylink.dinoex.sub.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: <E2E2BBF5-3694-4BCC-A83F-4F07C377A53E@iitbombay.org> In-Reply-To: <CAM5tNy6-=BqcwpsC==QemJua70taAYFYB0=4P3LaO53TKoiy8Q@mail.gmail.com> References: <CAM5tNy4cpC0a_Bgngi_wJt_h_FwoVnDT5c3ozr7b4O_M0Kx5pA@mail.gmail.com> <2100145914.14642.1762672441817@localhost> <CAM5tNy6-=BqcwpsC==QemJua70taAYFYB0=4P3LaO53TKoiy8Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 9, 2025, at 12:52 AM, Rick Macklem <rick.macklem@gmail.com> wrote: > > On Sat, Nov 8, 2025 at 11:14 PM Ronald Klop <ronald-lists@klop.ws> wrote: >> >> 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) > > 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E2E2BBF5-3694-4BCC-A83F-4F07C377A53E>