Date: Sun, 9 Nov 2025 08:14:01 +0100 (CET) From: Ronald Klop <ronald-lists@klop.ws> To: Rick Macklem <rick.macklem@gmail.com> Cc: 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: <2100145914.14642.1762672441817@localhost> In-Reply-To: <CAM5tNy4cpC0a_Bgngi_wJt_h_FwoVnDT5c3ozr7b4O_M0Kx5pA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Van: Rick Macklem <rick.macklem@gmail.com> Datum: 9 november 2025 00:23 Aan: FreeBSD CURRENT <freebsd-current@freebsd.org> CC: Peter 'PMc' Much <pmc@citylink.dinoex.sub.org> 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 adhere to the locking. Is this a lock different than file locking from user space? Why can’t this tail a file that is being written by copy_file_range if none of the applications request a lock? Regards, Ronald. [-- Attachment #2 --] <html><head></head><body><br><p><small><strong>Van:</strong> Rick Macklem <rick.macklem@gmail.com><br><strong>Datum:</strong> 9 november 2025 00:23<br><strong>Aan:</strong> FreeBSD CURRENT <freebsd-current@freebsd.org><br><strong>CC:</strong> Peter 'PMc' Much <pmc@citylink.dinoex.sub.org><br><strong>Onderwerp:</strong> RFC: Should copy_file_range(2) return after a few seconds?<br></small></p><blockquote style="margin-left: 5px; border-left: 3px solid #ccc; margin-right: 0px; padding-left: 5px;"><div class="MessageRFC822Viewer do_not_remove" id="P"><!-- P --> <!-- processMimeMessage --><div class="TextPlainViewer do_not_remove" id="P.P"><!-- P.P -->Hi,<br> <br> Peter Much reported a problem on the freebsd-fs@ mailing<br> list on Oct. 21 under the Subject: "Why does rangelock_enqueue()<br> hang for hours?".<br> <br> The problem was that he had a copy_file_range(2) copying<br> between a large NFS file and a local file that was taking 2hrs.<br> While this copy_file_range(2) was in progress, it was holding<br> a rangelock for the entire output file, causing another process<br> trying to read the output file to hang, waiting for the rangelock.<br> <br> Since copy_file_range(2) is not any standard (just trying to<br> emulate the Linux one), there is no definitive answer w.r.t.<br> should it hold rangelocks. However, that is how it is currently<br> coded and I, personally, think it is appropriate to do so.<br> <br> Having a copy_file_range(2) syscall take two hours is<br> definitely an unusual case, but it does seem that it is<br> excessive?<br> <br> Peter tried a quick patch I gave him that limited the<br> copy_file_range(2) to 1sec and it fixed the problem<br> he was observing.<br> <br> Which brings me to the question...<br> Should copy_file_range(2) be time limited?<br> And, if the answer to this is "yes", how long do<br> you think the time limit should be?<br> (1sec, 2-5sec or ??)<br> <br> Note that the longer you allow copy_file_range(2)<br> to continue, the more efficient it will be.<br> <br> Thanks in advance for any comments, rick<br> <br> </div><!-- TextPlainViewer --> <hr> </div><!-- MessageRFC822Viewer --> </blockquote><br><br>Why is this locking needed?<div>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.</div><div>Is this a lock different than file locking from user space?</div><div>Why can’t this tail a file that is being written by copy_file_range if none of the applications request a lock?</div><div><br></div><div>Regards,</div><div>Ronald.</div><div><br></div></body></html>help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2100145914.14642.1762672441817>