Write Back (safe) + Pure Storage – sinnvoll für produktive Windows-Server?

Sep 11, 2025
40
12
8
Hallo zusammen,

wir betreiben Proxmox 9.1 mit einem Pure Storage FlashArray (iSCSI+ multipath, 25 Gbit) und mehrere Windows-Server (u. a. Terminalserver).

Zum Test habe ich bei einer VM den Cache auf „Write Back (safe)“ gestellt.
Mit CrystalDiskMark war die Performance (v. a. 4K Random Writes) bis zu 10× höher im Vergleich zu „No cache / Write through“.
Auch die Nutzer-Performance im Terminalserver ist merklich besser.

In der Doku wird das extra erwähnt und ich lese das als "mach das" :)
  • For your virtual hard disk select "SCSI" as bus with "VirtIO SCSI single" as controller. Set "Write back" as cache option for best performance (the "No cache" default is safer, but slower) and tick "Discard" to optimally use disk space (TRIM). For the best performance, also make sure that IO Thread is enabled.

Meine Fragen:
  1. Ist „Write Back (safe)“ in Kombination mit Pure Storage Array für produktive VMs unbedenklich? -> macht ihr das auch?!
  2. Gibt es Best Practices oder Erfahrungen dazu?
  3. Würdet ihr das global für Windows-Verwenden oder nur selektiv?
  4. Empfehlungen für weitere Einstellungen? (SCSI-Controller, iothread, virtio usw.)
Umgebung:
  • Proxmox 9.1
  • Pure Storage FlashArray via iSCSI + multipath
  • Windows Server 2019/2022
  • Terminalserver + FSLogix
  • USV vorhanden

Danke für eure Erfahrungen!
 
Hallo @j.gelissen,

die beobachtete Leistungssteigerung (insb. bei 4k Random Writes) ist bei Windows mit "Write Back" normal, da der Host die Schreibzugriffe im RAM puffert und gebündelt an das Storage weitergibt.

Zur Sicherheit:"Write Back" ist in Proxmox konsistenzsicher, da Flush-Befehle von Windows respektiert werden. Das einzige verbleibende Risiko ist ein harter Stromausfall des Hosts (Daten im RAM gehen verloren, bevor sie das Storage erreichen). Da eine USV vorhanden ist, ist dieses Risiko für Terminalserver meist vertretbar.

Empfohlene Settings für Pure Storage (iSCSI):
  • Controller: VirtIO SCSI single
  • Cache: Write back
  • Discard: on (essenziell für FlashArray)
  • IO Thread: on
  • Async IO: io_uring
Du kannst das so produktiv nutzen.
 
  • Like
Reactions: Johannes S
@j.gelissen,

ja, Discard lässt sich nachträglich in den Hardware-Optionen der Disk aktivieren. Damit Windows die Änderung sicher als Feature der virtuellen Disk erkennt, ist ein kompletter Neustart (Stop/Start) der VM empfehlenswert.

Es ist nicht gefährlich für die Datenintegrität, wenn es aus ist. "Essenziell" bezog sich auf die Speichereffizienz: Ohne Discard (TRIM) erfährt das Pure Storage Array nie, wenn du Dateien in Windows löschst. Das Array behält die Datenblöcke belegt, und dein physischer Speicher läuft voll, obwohl Windows noch freien Platz anzeigt.

Nach dem Aktivieren und Neustart solltest du in Windows einmal die Laufwerksoptimierung (Defrag/Trim) manuell anstoßen, um den ungenutzten Platz rückwirkend freizugeben.
 
@j.gelissen,

ja, Discard lässt sich nachträglich in den Hardware-Optionen der Disk aktivieren. Damit Windows die Änderung sicher als Feature der virtuellen Disk erkennt, ist ein kompletter Neustart (Stop/Start) der VM empfehlenswert.

Es ist nicht gefährlich für die Datenintegrität, wenn es aus ist. "Essenziell" bezog sich auf die Speichereffizienz: Ohne Discard (TRIM) erfährt das Pure Storage Array nie, wenn du Dateien in Windows löschst. Das Array behält die Datenblöcke belegt, und dein physischer Speicher läuft voll, obwohl Windows noch freien Platz anzeigt.

Nach dem Aktivieren und Neustart solltest du in Windows einmal die Laufwerksoptimierung (Defrag/Trim) manuell anstoßen, um den ungenutzten Platz rückwirkend freizugeben.
Wir nutzen Proxmox im Cluster mit iSCSI + Multipath auf einem Pure Storage Array und haben uns deshalb für LVM thick entschieden (Stabilität / Cluster-Tauglichkeit mit Multipath).

Jetzt zur Frage:

Wirkt Discard / TRIM in so einem Setup überhaupt bis zum Array?

Nach meinem Verständnis terminiert LVM thick UNMAP/Discard, d. h. selbst wenn:
  • Discard an der VM-Disk in Proxmox aktiviert ist (VirtIO SCSI)
  • im Gast fstrim (Linux) bzw. ReTrim (Windows) ausgeführt wird
…sieht das Pure Storage Array davon nichts, weil das LUN für das Array immer vollständig allokiert bleibt.

Heißt das im Umkehrschluss:
  • ✔ Datenintegrität unkritisch
  • ❌ keine echte Rückgabe von freiem Speicher an das Array
  • ✔ nur logische Freigabe innerhalb des LV
Und wäre für echte Speicherfreigabe auf Pure Storage in Proxmox zwingend LVM-thin (oder ein anderes discard-fähiges Backend) nötig?

Bestätigt jemand diese Annahme aus der Praxis?