From nobody Wed Oct 13 19:16:57 2021 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 BC3C1180FA82 for ; Wed, 13 Oct 2021 19:17:01 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HV2Mx4dBcz4nK6; Wed, 13 Oct 2021 19:17:01 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f26:fa00:d066:1f81:2b65:dd01] (p200300cd5f26fa00d0661f812b65dd01.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:fa00:d066:1f81:2b65:dd01]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id F14B02A121; Wed, 13 Oct 2021 19:17:00 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <540e31f1-1403-073c-201d-a4495c0a8226@freebsd.org> Date: Wed, 13 Oct 2021 21:16:57 +0200 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Content-Language: en-US To: Alan Somers , Rick Macklem Cc: FreeBSD Current References: From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------rAniKDyxOGZkJfpaCq0OESz0" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rAniKDyxOGZkJfpaCq0OESz0 Content-Type: multipart/mixed; boundary="------------EEdhK1bOA4Das8gBMjlZTkpN"; protected-headers="v1" From: Stefan Esser To: Alan Somers , Rick Macklem Cc: FreeBSD Current Message-ID: <540e31f1-1403-073c-201d-a4495c0a8226@freebsd.org> Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd References: In-Reply-To: --------------EEdhK1bOA4Das8gBMjlZTkpN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 10.10.21 um 05:52 schrieb Alan Somers: > On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrot= e>> This leads me to a couple of questions: >> - Is there a good reason for not using vop_stdallocate() for ZFS? >=20 > Yes. posix_fallocate is supposed to guarantee that subsequent writes > to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > file system, cannot possibly guarantee that. See SVN r325320. This is not entirely true: ZFS supports reservations and it could thus support the pre-allocation of space that is later "filled". This reservations would be substracted from the free space sum, and it would be guaranteed that this free space is available for the file for which the pre-allocation has been requested. This would require that the allocate() call recorded the block range for which an allocation is requested (and for which no disk blocks are currently allocated) without assignment of any backing blocks at that time. Later writes to that range would allocate disk blocks and at the same time reduce the amount that is reserved and remove that range (that is now allocated) from the recorded pre-allocation range. This would of course require the addition of block ranges that are reserved but not yet backed by disk blocks to the znode, and of the total count of blocks reserved for this purpose in addition to other types of reservations in a separate variable. >> - Should I try and support both file system types via vop_stdallocate(= ) >> or not support Allocate at all? >=20 > Since you can't possibly support it for ZFS (not to mention other file > systems like fusefs) you'll have to not support it at all. While I do think that an allocate() operation could be implemented in ZFS, it is obvious that this does not apply to all possible fusefs filesystems (which do not even need to support the concept of an allocation of blocks or ranges). Regards, STefan --------------EEdhK1bOA4Das8gBMjlZTkpN-- --------------rAniKDyxOGZkJfpaCq0OESz0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmFnMKkFAwAAAAAACgkQR+u171r99UTX uggAoaiHzUyFTltPYsFAUFoNXWblniMk8WAHwOQ9gDGDIuwIJ04UR+F3n0HXDE23S7T4PBLl6qxB z9NVrAgcr1/kAypCtltWgtJwrHymlME/JdwjiBz7hp2yZoGGHfikrPa4LklcRsPjQEL/4cVBg//d JDElHDXbH1NgAN+kZbtF5a1zBkn4gxaQAInt/ixi7uJ5YM2wx/TUVntb9fIg7O2ujpnjzzr9cJcb gLvaT/Nl9XnjMvOBIn93lvDPaJlcbl8zySPj2jSVZGZUX6dIj5jz2WmGhLg89IMfFU9BFC6DwFBd eFDBRZCew5k+QsjB03SHG2m18TmQFPrmVqPsA/AwAQ== =cXQE -----END PGP SIGNATURE----- --------------rAniKDyxOGZkJfpaCq0OESz0--