From nobody Sun Nov 09 02:09:15 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 4d3x7f0L2bz6G1m6 for ; Sun, 09 Nov 2025 02:09:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4d3x7d5YgMz3hV4 for ; Sun, 09 Nov 2025 02:09:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-6407e617ad4so3246394a12.0 for ; Sat, 08 Nov 2025 18:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762654167; x=1763258967; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uKJagq//uHmn5zXDLtOHMNYzzwZdJfI2JThImECbdPE=; b=bTEcdTILnFOhB4sjn8OzxeZ6fSsMZO7T8a4YKiSk+ABDkHDEANy0tkTNhmKFl6wllK Ry9A/G6I63YDEcphCsE5QBcuKAfmv43e0GnpQyp6uRWzLWVJXc4ryTOpP75AKfRbEvIX g2/BFNCWZBWnS41eiLBOnijuBO+NozeF9Bvg4fCexgrULMft8JZ4lz7yYUdIkebTCh5t 6LRq6/8efb2VPWhdW9FIHyJYDSFldBM0PsBMU6dJM4pWhupB8GESmEeYudya9zx/lnac QZ1SNkZeTlJrGtyGlifNlYlygnHpdN2JRffFi4Z4rIO8CssE1RPKLftF9EOIKsWJaWdj aXGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762654167; x=1763258967; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uKJagq//uHmn5zXDLtOHMNYzzwZdJfI2JThImECbdPE=; b=H/eggWmOU9XEFkeuIByWmXPZUsHAVeTn6leJScZsc8E+HFvHVU8OwUfw9ooflK5yDv TuNK4i6NXCGBjQGf/aZ3Gq9EY0vmDahGc/bxWlc6HiD1eTA09yvZ0RBtoX6EWMJtRH6+ eDfkZiOsMOfi/WZ/730IjqrEFAofaomXrYclpZToTf1NYlb/njWxofT3YtgNppXpw8Ib XiYBMJ0TiAZ6x5nf9vNZZ59UdOKP3B3g17VCnKeTajgA/ZQNYYdcIGYMCbyed0n+uTpW nScykOXOzARVoY974+AyozgP+cS456pllwF7dmmlcYTmgHfDpYZ55k0t1efuhrjeNwRK gHYg== X-Gm-Message-State: AOJu0YwlQNxOz+5vs35c9aZPWZ6YcydziovwVoi/3GpLCuVmXCBmdPjo 6Xiq5ZlpFHax5CTaJ3VVQ635NLXb7DCL0DejCg3pLRTuoArt+S5rVdtOLSacb4wuefZeTnCmWIV cggXG7cTxsAKFORgmF7wVHhgvQ4otNQ== X-Gm-Gg: ASbGncuoe6ogQagjcReB/cxHACsMePFaVTvtYpQ+35ExfY6h0iXXal6N8hp+UyEyJXn DEYF3s2clHCv2wKmLkvInJw+khpFi/7cECIH+R+5U36/J5Yfki9IrO5FkPMiYkUSXrBBU6d5tRH mC2X7uTN47ZVecR2ivkGzqXapp/ckQ94T211j6KdV6Q5Hgdz8/4LoeqDYLX0a2AFGgccArDuRUu x65/DoM3p+5Y5CCN4squgk082pZ3nF20vh5M2gGdyuL2V82drPe1JhkeHMaVuufWFAK8WXO4pLQ CB+dVEGTlJhovFxs X-Google-Smtp-Source: AGHT+IGBB2K+Uq5Ryg36qlyet5qn2m31W3R+Ioz5t0XgFWkLWbKHB7hTo3lcVGaAIT/ttpFZWTCPf0G06umMOJyayl4= X-Received: by 2002:a05:6402:1d54:b0:641:270:2c8a with SMTP id 4fb4d7f45d1cf-6415a27829bmr3689433a12.14.1762654166989; Sat, 08 Nov 2025 18:09:26 -0800 (PST) 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 References: In-Reply-To: From: Rick Macklem Date: Sat, 8 Nov 2025 18:09:15 -0800 X-Gm-Features: AWmQ_bmpfQ7gKgwGw5RUQGbtMSqhLp5pv1CyPGIi05IcF7uvJtQnM_IXLPJLjRw Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Konstantin Belousov Cc: FreeBSD CURRENT , "Peter 'PMc' Much" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d3x7d5YgMz3hV4 On Sat, Nov 8, 2025 at 4:43=E2=80=AFPM Konstantin Belousov 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 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.) 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