Date: Wed, 5 May 2021 17:18:34 -0700 From: Mark Millard <marklmi@yahoo.com> To: Yuri Pankov <yuripv@FreeBSD.org> Cc: freebsd-current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: zpool list -p 's FREE vs. zfs list -p's AVAIL ? FREE-AVAIL == 6_675_374_080 (199G zroot pool) Message-ID: <164F9986-FB9C-43A9-ABC0-0D091D2CFF3D@yahoo.com> In-Reply-To: <34521f0b-a7a1-1743-244a-4149e72911a0@FreeBSD.org> References: <EAD6A790-EE50-4C3E-855E-CC4A83C25FF0.ref@yahoo.com> <EAD6A790-EE50-4C3E-855E-CC4A83C25FF0@yahoo.com> <34521f0b-a7a1-1743-244a-4149e72911a0@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-5, at 17:01, Yuri Pankov <yuripv at FreeBSD.org> wrote:
> Mark Millard via freebsd-current wrote:
>> Context:
>>=20
>> # gpart show -pl da0
>> =3D> 40 468862048 da0 GPT (224G)
>> 40 532480 da0p1 efiboot0 (260M)
>> 532520 2008 - free - (1.0M)
>> 534528 25165824 da0p2 swp12a (12G)
>> 25700352 25165824 da0p4 swp12b (12G)
>> 50866176 417994752 da0p3 zfs0 (199G)
>> 468860928 1160 - free - (580K)
>>=20
>> There is just one pool: zroot and it is on zfs0 above.
>>=20
>> # zpool list -p
>> NAME SIZE ALLOC FREE CKPOINT EXPANDSZ =
FRAG CAP DEDUP HEALTH ALTROOT
>> zroot 213674622976 71075655680 142598967296 - - =
28 33 1.00 ONLINE -
>>=20
>> So FREE: 142_598_967_296
>> (using _ to make it more readable)
>>=20
>> # zfs list -p zroot=20
>> NAME USED AVAIL REFER MOUNTPOINT
>> zroot 71073697792 135923593216 98304 /zroot
>>=20
>> So AVAIL: 135_923_593_216
>>=20
>> FREE-AVAIL =3D=3D 6_675_374_080
>>=20
>>=20
>>=20
>> The questions:
>>=20
>> Is this sort of unavailable pool-free-space normal?
>> Is this some sort of expected overhead that just is
>> not explicitly reported? Possibly a "FRAG"
>> consequence?
>=20
> =46rom zpoolprops(8):
>=20
> free The amount of free space available in the pool. By contrast,
> the zfs(8) available property describes how much new data can =
be
> written to ZFS filesystems/volumes. The zpool free property is
> not generally useful for this purpose, and can be substantially
> more than the zfs available space. This discrepancy is due to
> several factors, including raidz parity; zfs reservation, =
quota,
> refreservation, and refquota properties; and space set aside by
> spa_slop_shift (see zfs-module-parameters(5) for more
> information).
Thanks for pointing to the reference material.
6_675_374_080/213_674_622_976 =3Dapprox=3D 0.03124 =3Dapprox=3D 1.0/32.0
and spa_slop_shift's description reports:
QUOTE
spa_slop_shift (int)
Normally, we don't allow the last 3.2%
(1/(2^spa_slop_shift)) of space in the pool to be =
consumed.
This ensures that we don't run the pool completely =
out of
space, due to unaccounted changes (e.g. to the MOS). =
It
also limits the worst-case time to allocate space. =
If we
have less than this amount of free space, most ZPL
operations (e.g. write, create) will return ENOSPC.
Default value: 5.
END QUOTE
So in my simple context, apparently not much else
contributes and the figures are basically as
expected.
Thanks again.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?164F9986-FB9C-43A9-ABC0-0D091D2CFF3D>