Date: Wed, 13 Oct 2021 21:16:57 +0200 From: Stefan Esser <se@freebsd.org> To: Alan Somers <asomers@freebsd.org>, Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Message-ID: <540e31f1-1403-073c-201d-a4495c0a8226@freebsd.org> In-Reply-To: <CAOtMX2hyoyLam%2BOY7_hziiX7%2BEP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com> References: <YQXPR0101MB0968322C2DEBFAA672FFBC8EDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2hyoyLam%2BOY7_hziiX7%2BEP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rAniKDyxOGZkJfpaCq0OESz0 Content-Type: multipart/mixed; boundary="------------EEdhK1bOA4Das8gBMjlZTkpN"; protected-headers="v1" From: Stefan Esser <se@freebsd.org> To: Alan Somers <asomers@freebsd.org>, Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Current <freebsd-current@freebsd.org> Message-ID: <540e31f1-1403-073c-201d-a4495c0a8226@freebsd.org> Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd References: <YQXPR0101MB0968322C2DEBFAA672FFBC8EDDB49@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <CAOtMX2hyoyLam+OY7_hziiX7+EP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com> In-Reply-To: <CAOtMX2hyoyLam+OY7_hziiX7+EP8h2Ca4qiTpkj8suKZnkv68g@mail.gmail.com> --------------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 <rmacklem@uoguelph.ca> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540e31f1-1403-073c-201d-a4495c0a8226>