Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Feb 2021 03:11:55 +0800
From:      Ka Ho Ng <khng@freebsdfoundation.org>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        Ka Ho Ng via freebsd-arch <freebsd-arch@freebsd.org>
Subject:   Re: Proposing space management API to perform hole-punching
Message-ID:  <39A2A13C-22C9-4386-B30F-0EBEE5E89AC4@freebsdfoundation.org>
In-Reply-To: <82972.1613070046@critter.freebsd.dk>
References:  <17D576F5-FBB9-425A-B6AB-B6CBA97ED785@freebsdfoundation.org> <82972.1613070046@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 12, 2021, at 3:00 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> =
wrote:
>=20
> --------
>=20
> Ka Ho Ng via freebsd-arch writes:
>=20
>> The proposal contains fspacectl(2), VOP_DEALLOCATE(9) and =
vn_deallocate(9). fspacectl(2) is a space management API that takes a =
file descriptor, a command value, a range and flags.  The system call is =
responsible for doing space management operations such as punching =
holes, which is the only operation supported so far. [...]
>=20
> 1. Which other operations are/can be foreseen ?
Besides SPACECTL_DEALLOC, it would be foreseeable to implement =
SPACECTL_ALLOC.
>=20
> 2. What arguments would they need ?
The same, a tuple of offset and length.
>=20
> 3. Should the syscall definition take this into account already now ?
kib@ thinks it is a bonus to simplify the number of system calls in the =
original fdeallocate(2) +
fzero(2) draft under the same differential, as we already got =
posix_fallocate.
Besides, one of the consideration behind is to implement linuxulator=E2=80=
=99s fallocate, which does
also does FALLOC_FL_KEEP_SIZE.=20
>=20
> 4. Are there any existing APIs for this ?
> 5. Should we stick closely to them ?  If not, why not ?
posix_fallocate. The system call however does not consider the case if =
file extending is not
required, nor does it do hole-punching.
>=20
> --=20
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe   =20
> Never attribute to malice what can adequately be explained by =
incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39A2A13C-22C9-4386-B30F-0EBEE5E89AC4>