From nobody Tue Nov 11 22:09:50 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 4d5gh25451z6H6Jw for ; Tue, 11 Nov 2025 22:10:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 4d5gh21yzrz3G8m for ; Tue, 11 Nov 2025 22:10:10 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b6d402422c2so42432966b.2 for ; Tue, 11 Nov 2025 14:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762899004; x=1763503804; 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=yDs2EPKFsjcusDaqR7IOaPGNFqCcmp3kZLCxsuh25sk=; b=Oly8TQOJLp08bbCPSKgDlV1w58SZduZjAZ56AYn5oyB2zZOskTAITrjnXFgotShHD6 FbGYwzkHhga/CD1iqBgh4jkold/2+MevV8dvxfgNTbkSMpjuNJFCxrlCAOB7gL4PzbUI TUUkMk9fA/m4g+UA5DyjldvdzpaKjjpImMOVqoa6OhVyMa03wW5zF63cC/Tb2Okk4qa4 zFVCUqDeoVhRGPVJUzHYq9GB02RG8sRgnf4jBn9xDUExvY9VYXFMvrSXeeij7NKh75k6 TvWJa/+iXTOiII4TFFEBv9BnrKQCo5MOFLtt9SFuecXlTgUinMM8W0sMev6EM2uO7J/u rSoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762899004; x=1763503804; 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=yDs2EPKFsjcusDaqR7IOaPGNFqCcmp3kZLCxsuh25sk=; b=rigLUjzoMQvb+r084zNYYqh5VSaaMLE5Yvu9wsdvUI5QZs5IEJsoRtBJNRTmwawUGV tqS46N3h4RLMyyeh/k1iPyNoJa9XD+DGMeUv+Y8kxqqTFDkjOd52p4pJnqf6EbsfVqd4 roi+PlWBLmd9d3xygAdf+F/u1zH7UtFyF4zy6yB1xV365qwVXOkMm4rMOxAcpxumRu3F tC2d0sJOW7Pm1wmkPBiH8QEulG1ZFS27Ipe5RPNUMgQ2sa1UbXhb5GUN2xSq0NPXLRJl VM1J1Z4AXGNrpcdI9Tvt93QudvCIUdD2UGr/CHqPkmMrShfqBAjs60sNXh00a66FPEtB FZMg== X-Forwarded-Encrypted: i=1; AJvYcCVUyVTWiCgiyU0mdDNUN6wnjf3oL7F0WZhRUzUqKV3RshiyhmP0117a+T3Q71dBBsV0fYGsqDmibGUAfngml7c=@freebsd.org X-Gm-Message-State: AOJu0YyEU9lMbzyChclF5zEe/njnMMK1ej3KffKiaDHnbPUiqbucCXU/ DlBZLnvjDTN8sjF6XzAUBkgTad7jEn/eZHEGQL8IdNT52oc6H2A/bkR/4N7tFb4lcf3sKqNaf0e /SPTYy0C8z0WkFBgslUkFXmXsxkhK3m9kifo= X-Gm-Gg: ASbGncsX3vqZmilC+ZJDILehb7aO+IcRF3OBUt2If9/F4EBOYTBfUZQVLR+YYLpj3qL eNYGG7ir1o/VqROpDVDTRdPh7ugjTlbF1g1v4O83f27djnJ+egYt6LEiejypKl/7ruEmcyOB05k ++luUZgjS1/zX6mKYvrhZViqdXWtuppGNnaoFchsrAkDltjVQFRwyLBxPjld9w3J1KAgry1rIO/ lLK/bjt8Lk4ZStzl310v4FLkfhiwhuCvces8ng51Uf9exJB0a02lURnUOAbaIFr5+u+Qw== X-Google-Smtp-Source: AGHT+IGXP5SG7OeW4aX4V6p7Xlt1CwnW/GDDzsJMS+o5+WH4owYuZ9L0D/YeoCKcmFGRYpx9nvCurb9wc3xt+HRA4iU= X-Received: by 2002:a17:907:2d2c:b0:b70:b71a:a5ae with SMTP id a640c23a62f3a-b7331aa3be1mr77126966b.44.1762899003793; Tue, 11 Nov 2025 14:10:03 -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: From: Rick Macklem Date: Tue, 11 Nov 2025 14:09:50 -0800 X-Gm-Features: AWmQ_bkKEZ_4YjOzBUpC_CJlTx5kQs2GRxxgs14OqrzEqoDrRSbb_N_yO3K0NFU Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: "Peter 'PMc' Much" Cc: Bakul Shah , Ronald Klop , 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)[]; 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: 4d5gh21yzrz3G8m On Tue, Nov 11, 2025 at 6:54=E2=80=AFAM Peter 'PMc' Much wrote: > > On Mon, Nov 10, 2025 at 12:58:17AM -0800, Bakul Shah wrote: > ! On Nov 9, 2025, at 12:52=E2=80=AFAM, Rick Macklem wrote: > ! > > ! > On Sat, Nov 8, 2025 at 11:14=E2=80=AFPM Ronald Klop wrote: > ! >> > ! >> 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? > ! > 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-Octobe= r/004704.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.) > ! > ! Traditionally reads/writes on Unix were atomic but that is not the > ! case for NFS, right? That is, while I am reading a file over NFS > ! someone else can modify it from another host (if they have write > ! permission). That is, AFAIK, the POSIX atomicity requirement for > ! ead / write is broken by NFS except for another reader/writer on > ! the same host. > ! > ! Another issue is that a kernel lock that is held for a very very > ! long time is asking for trouble. Ideally one spends as little time > ! as possible in the supervisor state and any optimization hacks > ! that push logic into the kernel should strive to not hold locks > ! for very long so that things don't grind to a complete halt. > ! > ! That is, copy_file_range() use in cat(1) seems excessive. The only > ! reason for its use seems to be for improving performance. > > Not really. ZFS can do what might be best described as > "block-level hardlinks": if you copy an entire block, it is not copied > at all, and, also quite interesting, it doesn't need diskspace. > It is just listed as duplicate. > > So, how big is a ZFS block? That depends - the default was 128k, but > now often desired is 1M, and people are already talking about 16M (not > sure if that makes any sense, but probably they will come for 256M > sooner or later :/ ). > > I could imagine some kind of max-copy-file-rangelock setting with a > default of 16M, and tunable for better or worse if really needed. > But that is an operator's viewpoint, I do not know if this is > feasible from design/implementation. > > ! Why not > ! break it up in smaller chunks? That way you still get the benefit > ! of reducing syscall overhead (which pales in comparision to any > ! network reads in any case) + the same skipping over holes. Small > ! reads/wries is what we did before this syscall raised its head! > > Out of curiosity I tried to look at practical size parameters for > read()/write() syscalls - and that runs with 1GB blocksize, if you > really want it. So if you do > $ dd if=3D/dev/random of=3D./XX bs=3D1073741824 > $ cat ./XX > the cat will wait until the first block is completely > written, and then deliver exactly 1GB. Yes. A large read(2) will exhibit the same property (rangelocked so other reads are blocked). It's just that read(2) doesn't normally use really large blocks (as others noted, 16Mbytes is probably the largest useful size now or in the near future) whereas using a large size for copy_file_range(2) is useful. I suppose you could argue for using 16Mbytes instead of SSIZE_MAX, but I think that will still end up with increased overheads for ZFS, since it will require many syscalls instead of one. I am not at home, but when I get home in a couple of seeks I'll see how long it takes to copy a large file on ZFS with block cloning enabled on my very slow hardware with no separate ZIL device. rick > > > cheers, > PMc