Van: Rick Macklem <[email protected]> Datum: 9 november 2025 00:23 Aan: FreeBSD CURRENT <[email protected]> CC: Peter 'PMc' Much <[email protected]> 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.
