From nobody Sun Nov 09 08:52:38 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 4d46564Ll8z6GWLM for ; Sun, 09 Nov 2025 08:52:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 4d46562950z3TFf for ; Sun, 09 Nov 2025 08:52:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64165cd689eso1151722a12.0 for ; Sun, 09 Nov 2025 00:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762678370; x=1763283170; 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=ra+kdZAQe9q2GXzirnlDBvPR0mKyggTmfFxHQdhZuk0=; b=UlyiYDtmyo1Hb5TPVVtzKeRKKB6N2IgCJNk8ORDqJLHZ4sJQwsrDDF3hH4cvvggKY6 0KsRL1hDYz1Fpcyw4iCh1O5CWmCbob+f+7rV8DHWpKdUhOqdH/4+P3i4EEreNGd8skmY z+dX7b+35DTrrzsY/9XAUVu/eYXXHRQ8zW+3xYL/8DEvrGNOYo4HuXCNoCzYxUO8728X zAmOqVkQaNPSnkYJ/muoaEuCfurXyhBctl6QcO2OMO5pcqj9p2ZCbhBAdQyOxNwW63ys tbg0qTBPluLVflm0OaIz+qyvT3oamJ89og7YSQK5InM1tEXCrG+ZY/av25g1LndopeKb QJQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762678370; x=1763283170; 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=ra+kdZAQe9q2GXzirnlDBvPR0mKyggTmfFxHQdhZuk0=; b=f42NaxZ3XtPIs1bU0O16QGpO139QaVZ8TScOLP0lEUeGH7BHqtTMIilYGS+tQGM+Km vYkLG2kM32urtqZzjJFZwXMaz3FlvcchuQSqrjgGT6OlvrjX/8L0tUC1iU6aMxnrAtcV qyLTJGnXGSSMevoxkqngT7xhSG0UudtQnMqcf6EEFtWZ8CYeB5M0OPf03EQ0ZjMSo4GR Kwg6QXX28HplIzKL2wNXJKkdXvDGPbRP/+bJz/e1vElRKgkdTpFNjY56n7w74RIPLS7W YfeBF0jOPNyOIWyoN/wkD1IMQ9OTccSKAuOQJCswup60yNcAAOv91RaKjiqrEt8ty0qT pRCg== X-Forwarded-Encrypted: i=1; AJvYcCWBlYmh2woUx+rOwMBF0egSGD/EpcL4xdFcQY85YEnpaafARR14GJxDu3HeAQQifsq9Sd0nJ8eZG+xkGYYTUjo=@freebsd.org X-Gm-Message-State: AOJu0YwK9c1lU0SPn9dM7ONTP5i7SlH329TbpnJn2DGN0tevoCqv9Cc0 E1E/BZNHxI2PiGKqcsIhesgqQY1dbWOPP+no10KBE66JVeVS+M4aiwxb17uqhDRpCK3/TbjlOHj iEqAYfcEztuxLLhqwVtSjySHUVH8Nt0U2h+Rn5A== X-Gm-Gg: ASbGncsf/Qliu5Ul6CJpyFFuHCtP9MNbPYSl6R/RrrjdR2tmL2hkHUfYSF1W43jlKe+ bGj04fteATxAN0ADEOifGvXzOdz6tVupORIyiQmFB2W4JW0d0M7vq0WqnjMWUIHtCpdBaKO0Zbd mF63llreB5Eq2Wwp5x6Z0rIo14qNvYurunUwqiIoFxhnGSBVk/Atad85HPXqGb4dvJ6lPQ7v/VU A4KzqQLFCeaBrtGuLgmwscZcpRnI+sVnAlFcoSDhaB+GYPYy/JTazfmFT02Kj+0pOnExRLvNCfr cLK1NyV8GAOg2lUk5Pw9CNPZ2Cs= X-Google-Smtp-Source: AGHT+IEOV81SdWDrI1P5msFrd6rrA8x3G91GBbv/JOrf3E+t0rlnkLNTiwZa566wYtpgcVFXyTGkMbH/XmGfKuEEPrY= X-Received: by 2002:a05:6402:454a:b0:640:931e:ccac with SMTP id 4fb4d7f45d1cf-64146f33e02mr4711274a12.7.1762678369982; Sun, 09 Nov 2025 00:52:49 -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: <2100145914.14642.1762672441817@localhost> In-Reply-To: <2100145914.14642.1762672441817@localhost> From: Rick Macklem Date: Sun, 9 Nov 2025 00:52:38 -0800 X-Gm-Features: AWmQ_bmKnUScoLVbgUXNg_UBCaHYbszq0NYU8aVSLrqNG_k1wVPQ7kx3p-EVM7w Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Ronald Klop Cc: "Peter 'PMc' Much" , FreeBSD CURRENT 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)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d46562950z3TFf On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop = wrote: > > > Van: Rick Macklem > Datum: 9 november 2025 00:23 > Aan: FreeBSD CURRENT > CC: Peter 'PMc' Much > 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 w= riting the result is your own problem. It is up to the applications to adhe= re 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/0047= 04.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.) rick > Why can=E2=80=99t this tail a file that is being written by copy_file_ran= ge if none of the applications request a lock? > > Regards, > Ronald. >