Date: Sat, 8 Nov 2025 20:06:06 -0800 From: Rick Macklem <rick.macklem@gmail.com> To: Konstantin Belousov <kib@freebsd.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>, "Peter 'PMc' Much" <pmc@citylink.dinoex.sub.org> Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: <CAM5tNy44Bb=50zefq2cyfJwWVphDNVnF7MxJMJa%2Bp6UZm0CrLQ@mail.gmail.com> In-Reply-To: <aRANKfbsjXXEfNIU@kib.kiev.ua> References: <CAM5tNy4cpC0a_Bgngi_wJt_h_FwoVnDT5c3ozr7b4O_M0Kx5pA@mail.gmail.com> <aQ_jeyGqosXyPcgO@kib.kiev.ua> <CAM5tNy6WxWLdfdv3qA7ext_UV9gFznTsd79f1GockU7x1q=ttQ@mail.gmail.com> <aRANKfbsjXXEfNIU@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
On Sat, Nov 8, 2025 at 7:41 PM Konstantin Belousov <kib@freebsd.org> wrote: > > On Sat, Nov 08, 2025 at 06:09:15PM -0800, Rick Macklem wrote: > > On Sat, Nov 8, 2025 at 4:43 PM Konstantin Belousov <kib@freebsd.org> wrote: > > > > > > On Sat, Nov 08, 2025 at 03:22:37PM -0800, Rick Macklem wrote: > > > > 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 > > > > > > For me, making a syscall limited by runtime is very strange idea. > > > IMO it should not be done. > > > > > > What can be done, I think, is to add signal interruption points into > > > the copying loop. AFAIR we request a chunk to be copied, for some > > > size of the chunk. After the copy is done, kernel could use > > > sig_intr() to check for either interruption or suspend conditions. > > > If non-zero is returned, you might finish the loop earlier, reporting > > > the partial copy. > > > > > It already interrupts when a signal like <ctrl>C is posted. > > > > The reporter didn't want the copy (he was actually using "cat") > > to terminate. He wanted to read the output file when it was > > only partially copied, which doesn't work because of the > > rangelock. (It appears it does work on Linux.) > Apps can install timer which would generate SIGALRM after 1 or 2 secs. > Then the syscall is interrupted and partial copy is reported. Yep, although in Peter's case it was just "ca(1)t". Also, the timeout could be enabled via a flag in the flag argument to copy_file_range(2). That is probably simpler than a SIGALRM. (The current 1sec timeout flag for the NFS server is "in kernel only", but it's easy to expose it to the syscall. rick > > > > > A partial copy_file_range() is normal and an NFSv4.2 server > > will return a partial copy after 1sec or so since there is a > > general understanding (not wired down in any RFC) that > > an RPC should always reply in 1-2sec. > > > > rick >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy44Bb=50zefq2cyfJwWVphDNVnF7MxJMJa%2Bp6UZm0CrLQ>