hdparm -W zfs set atime=off local-ssd-zfs zfs set compression=lz4 local-ssd-zfs zpool iostat (affiche les stats cumulées...) zpool iostat 2 (pour rafraichir toutes les 2 secondes) #ajouter un disque log et cache zpool add -f test-zfs log /dev/sdxx cache /dev/sdxxx
### Trouvé sur le net ###
Symptom: Copying anything—even an ISO—caused I/O delay to spike to 40–90%, the VM froze, and the whole node choked. Even with only one VM and plenty of CPU/RAM. I know, I know…
“You’re not supposed to use consumer SSDs in production.” Totally agree. But sometimes a client chooses the budget they choose and the job is to make it work as safely as possible. Anyway… ✔️ The Root Cause ZFS synchronous writes + consumer SSDs = absolute misery. Consumer SATA SSDs have:
slow fsync latency tiny SLC caches no power-loss protection awful random write performance once the cache fills controllers that can stall under ZFS write patterns
Even with a 2-disk mirror, copying a file would hit the end of the SLC cache → SSD latency would jump → ZFS TXG flushes stalled → Proxmox I/O delay went crazy. I also spun up another test box at home using Intel DC enterprise SSDs and none of these issues showed up — so the hardware difference was the smoking gun. ✔️ The Fix These ZFS dataset settings instantly stabilized the system: zfs set sync=disabled rpool/data zfs set atime=off rpool/data zfs set recordsize=64K rpool/data What each does (short version):
sync=disabled → stops ZFS from forcing every tiny write to hit the SSD immediately. (Yes, slight risk during an unexpected power loss. We have a UPS and BDR.) atime=off → stops ZFS from doing metadata writes for every read. recordsize=64K → better block size for VM workloads.
After these changes:
ISO copies completed instantly I/O delay dropped from 90% → 1–5% Windows VM became responsive No more host freezing
Night and day.