GUI size of free space is incorrect

[EtienneB]

Hello,
I am running 12u5.1, but the issue was already there.
In the GUI the free available space is wrongly listed, as it does not take into account compression it seems.
I have a SSDpool which in the GUI says:

ssdpool(System Dataset Pool)ONLINE check_circle | 183.15 GiB (92%) Used | 16.42 GiB Free

Name	Type	Used	Available	Compression	Compression Ratio	Readonly	Dedup	Comments
ssdpool	FILESYSTEM	183.15 GiB	16.42 GiB	zstd	1.67

So only 16GB free space. While in the CLI I get:

NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
ssdpool 206G 112G 94.3G - - 54% 54% 1.00x ONLINE /mnt
mirror 206G 112G 94.3G - - 54% 54.2% - ONLINE
gptid/0ad46ee4-d5a0-11ea-8d48-002590f35a9e - - - - - - - - ONLINE
gptid/0c174218-d5a0-11ea-8d48-002590f35a9e - - - - - - - - ONLINE

So I have 94GB free? The difference does seemto be the 1.67 compression. I have the jails, VM and systemdataset on the ssdpool.

Couple of weeks ago I received emails that my SSDPool was out of space, and did indeed show almost 0 free space in the GUI. (At the time I didn't check the CLI to compare.)

My question is, besides the emails, am I running into issues with this pool when the GUI says 100% used?

I am also a bit puzzled by the 54% fragmentation on a SSD, which is irrelevant for an SSD. But would it slow down my pool?
I run a manual trim earlier today, but that didn't change anything. (the AUTO Trim is off by default and I left it that way)

Code:

zpool trim ssdpool

Any thoughts?
Thank you

 

[sretalla]

fragmentation on a SSD, which is irrelevant for an SSD. But would it slow down my pool?

Fragmentation in ZFS refers to the Free Space, not the used blocks.

When ZFS is preparing transaction groups, it has to work a lot harder when it needs to work to find the required contiguous blocks to summarize a transaction into the smallest possible operation, so highly fragmented free space can impact perfoemance for SSD pools too (it's not really clear at what point you would notice a difference though.

It's not really related to TRIM.

The difference does seemto be the 1.67 compression.

It is taken into account, so that makes sense.

am I running into issues with this pool when the GUI says 100% used?

If the pool is so full that you can't even find the space to write deletion transactions (remember that you're using Copy on Write), your pool can no longer be used for writing and is effectively read-only.

When in that state, you probably can't even replace disks in order to expand it, so it may be a permanent condition.

 

[EtienneB]

That is what I am afraid of. The CLI says 45% free (93Gb out of 206), while the GUI only report 11GB free....And the GUI triggers the warning email. (after I cleaned up some snapshots, I have free space in the GUI).