ZFS-Bug: PBS Chunks not compressed [solved]

[Tarakesh]

Hi together,
using PBS for a while now and it works great.
Also i absolutly know that the setup i'm about to post is not supported/recommended but i am not here to argue about that.

Setup:
PBS running as a VM on Promxox, Datastore mounted via NFS residing on a truenas box.
Storagelayout: 18 Disk (6xRaid2), Dataset: Recordsize 4M, Compression LZ4
Again: i am not here to argue about this setup as it has nothing to do with the issue.

It seems that the chunks PBS writes are not properly compressed before writing them to storage.

ZFS on Storage shows a compression ratio of 1.36x at the moment which should be impossible if the chunks that PBS writes are properly compressed.
It sometomes goes up to over 1.5x
i am expecting a more close to 1x, maybe 1,05x ratio.
1.36x ratio on already compressed chunks with LZ4(!) is quite significant.

zfs get for the Dataset
NAS/PBS refcompressratio 1.36x
NAS/PBS written 3.87T
NAS/PBS logicalused 5.28T

Versions used
proxmox-backup-server 4.1.1-1 running version: 4.1.1
For completion: PVE 9.0.11 (Kernel 6.14.11-4-pve), TrueNAS 25.10.1

 

[jlauro]

Only the parts under .chunks will be compressed. Also "free" space will also compress well. Unless your .chunks directory is >3.87T you are not getting as much from zfs as you think. Do a du -hs .chunks and how big is that?

 

[Tarakesh]

Only the parts under .chunks will be compressed. Also "free" space will also compress well. Unless your .chunks directory is >3.87T you are not getting as much from zfs as you think. Do a du -hs .chunks and how big is that?

a pure du-hs .chunks is useless on zfs as it shows diskusage after compression. so that will tell you exactly 3.87T
Pretty easy to proof with an example of a highly compressable SD Card Image
fg@truenas:/mnt/NAS/3DDruck/SDBackup/VT$ ls -lah vt.img
-rw-rw-r-- 1 1000 1005 30G Jan 27 2024 vt.img
fg@truenas:/mnt/NAS/3DDruck/SDBackup/VT$ du -h vt.img
5.1G vt.img

as you can see the image is 30GB in size but du -h reports 5.1GB which is exactly the size it has on disk after compression.

if you want to see size before compression aka true filesize you need du --apparent-size

but this makes things even weirder. seems like the size used is correct but the reported size by zfs is way off.
will check with the zfs folks.