Powerloss Protection (PLP) Mythos

floh8

Renowned Member
Jul 27, 2021
1,038
115
73
Ich habe mich früher schon gefragt, warum man eigentlich eine Batterie für einen Raidcontroller Cache braucht, wenn man denn 2 Netzteile und 'ne USV hat. Das man also ohne BBU den Cache nicht verwenden kann, fand ich damals schon dämlich.

Hier im Forum wird immer wieder betont, wie wichtig PLP bei SSDs ist, weil man dadurch deutlich mehr Performance bekommt. Ich habe mich damals schon gefragt, was PLP denn mit Performance zu tun hat. Da ich mich aber nicht auskenne, habe ich die Aussage einfach übernommen. Jetzt bin durch die horrenten Preise zu PLP SSDs wieder über die Frage gestolpert, ob ich denn wirklich PLP brauche. Wenn man im Internet danach sucht, findet man bei einigen SSD-Anbietern immer wieder die gleiche Erklärung: PLP-SSDs bringen zusätzliche Kondensatoren mit, die bei einem Stromausfall den flüchtigen Cache auf die Speicherzellen schreiben. Nun stellt sich mir aber weiterhin die Frage, was das mit Performance zu tun hat. So weit ich es noch im Kopf habe argumentieren, die Vertreter dieser Meinung wie folgt: Raid-Controller oder Raid-Filesysteme wie zfs deaktieren den Festplatten-Cache, damit gesichert ist, dass die Daten wirklich sicher geschrieben wurden. Wenn eine Platte aber PLP hat, wird der Cache nicht deaktiviert und darum ist die Performance besser. Siehe:https://www.reddit.com/r/storage/co...gain_of_plp_powerlossprotection_drives/?tl=de
Berichtigt mich, wenn ich es falsch wieder gebe! Meine Recherche ergab ein anderes Ergebnis. Da dieses Thema immer bei zfs aufkam, habe ich mich auch auf zfs konzentriert.
Leider kann ich es nicht nachprüfen, da ich hier keine zfs installation habe, aber die Quelle, die ich gefunden habe, behauptet, das zfs keinen Cache abschaltet, sondern davon ausgeht, dass er an ist und bei Sync-Writes manuelle Flush Commands an das Gerät senden. Siehe:https://serverfault.com/questions/995702/zfs-enable-or-disable-disk-cache/995729#995729

Prüfen kann man den Cache mit:

hdparm -W /dev/sda

Aus- und Einschalten mit:

hdparm -W 1 /dev/sda
hdparm -W 0 /dev/sda

Für mich ergibt das die Schlussfolgerung, dass der Performanceboost nicht mit PLP zu tun hat, sondern einfach der Tatsache geschuldet ist, dass man Enterprise SSDs einsetzt. Die haben eben noch ganz viele Spielerreien verbaut wie größeren Cache, bessere Cachezellen, besseren Controller usw. usf.

Wie kann man nun die Sync-Writes vom zfs noch beschleunigen, wenn man einen SLOG einsetzt oder Full-Flash fährt? Nun schlage ich den Bogen zu meinem Einleitungsthema. Ich beleuchte hier das Thema natürlich nur bezüglich einer professionellen Unternehmensumgebung. Wenn ich einen Server mit 2 Netzteilen und einer USV habe, dann ist der Stromausfall praktisch ausgeschlossen. Warum sollte dann das zfs regelmäßig flushen? Denn wenn es das tut, wartet es auch jedesmal auf die Rückmeldung, ob es passiert ist. Die Latenz des Storage steigt. Wäre es dann nicht sinnvoller diesen Vorgang im zfs zu deaktivieren? Ich denke ja.
Dies macht man indem man einen Paramter setzt (/etc/modprobe.d/zfs.conf).

options zfs zfs_nocacheflush=1
 
Hallo,

naja, das Hauptargument, wie ich es wahrgenommen habe, war nicht (nur) der Performanceboost, sondern auch die erhöhte Datensicherheit im Falle eines Stromausfalls. Was ich auch schlüssig finde: Je nach vorhandenen Netzwerk/Internetanbindung kann man die Performance ja eh nicht unbedingt ausnutzen im Homelab, aber Schutz vor Datenverlust finde ich immer nützlich ;)

Schöne Grüße, Johannes.
 
Nun stellt sich mir aber weiterhin die Frage, was das mit Performance zu tun hat. So weit ich es noch im Kopf habe argumentieren, die Vertreter dieser Meinung wie folgt: Raid-Controller oder Raid-Filesysteme wie zfs deaktieren den Festplatten-Cache, damit gesichert ist, dass die Daten wirklich sicher geschrieben wurden. Wenn eine Platte aber PLP hat, wird der Cache nicht deaktiviert und darum ist die Performance besser.
Nur mal ganz kurz; die Firmware einer SSD liefert irgendwann die Bestätigung nach oben, dass die Daten geschrieben wurden. Wenn es sich um einen "sync" Schreibvorgang handelt, bzw. vom OS ein "flush/sync" gemacht wird, sollte die SSD erst das ACK liefern, wenn direkt zu dem Zeitpunkt der Strom gezogen wird und es trotzdem zu keinem Datenverlust kommt.

Leider sind hier viele Consumer SSDs nicht ganz so genau, wie sie es sein sollten. Ich wollte auf einen älteren Twitter Thread verlinken, aber der Account existiert nicht mehr und archive.org findet (aktuell) auch nichts dazu. Aus dem Gedächtnis: die Person steckte diverseste Consumer SSDs an, schrieb Daten, machte einen flush und zog, nachdem der Befehl durch war (die SSD meldet alle Daten sicher geschrieben), die SSDs ab.
Im anschließenden Test, ob die Daten wirklich alle geschrieben wurden, war das Ergebnis sehr durchwachsen, und quer durch die Bank gab es genügend, bei denen die Daten nicht mehr vollständig vorhanden waren.

Wenn die Firmware es auch ernst nimmt, sollte man sehen, dass bei einem Benchmark, die Ergebnisse deutlich schlechter sind, sobald man mit der sync Option testet. Dann darf die SSD ja erst das ACK geben, wenn die Daten im nicht flüchtigen Chip liegen. Der ist aber meistens deutlich langsamer als der RAM der SSD (wenn sie denn noch einen eigenen RAM hat).

Bei Enterprise SSDs mit PLP, wo die Kondensatoren noch genug Strom liefern, kann die SSD die Daten, die im RAM-Chip liegen, bei Stromverlust diesen entsprechend noch auf die nicht flüchtigen Chips wegschreiben. Somit darf sie aber auch mit gutem Gewissen sync Writes schon ACKen sobald die Daten nur im RAM der SSD liegen!
Dadurch erbringen SSDs mit PLP in der Praxis bessere Performance im Vergleich zu Consumer SSDs die dich nicht anlügen.

Dazu kommt, dass Datacenter/Enterprise SSDs die Leistung in den Specs auch meist unter Dauerlast halten können.

Bei Consumer SSDs ist es ein Minenfeld, gute von schlechten auseinanderzuhalten. Berüchtigt sind die Samung QVOs, welche in den Specs ganz vernünftig aussehen, aber schon bei längeren Benchmarks mitunter so weit einbrechen, dass eine HDD flotter wäre!

So, genug gefaselt, gute Nacht ;)

---
Thread zu dem Thema hier von letztem Jahr (der Twitter Link ist drin, geht aber leider nicht mehr): https://forum.proxmox.com/threads/disk-cache-wiki-documentation.125775/
 
Last edited:
  • Like
Reactions: Johannes S
Ich habe mich früher schon gefragt, warum man eigentlich eine Batterie für einen Raidcontroller Cache braucht, wenn man denn 2 Netzteile und 'ne USV hat. Das man also ohne BBU den Cache nicht verwenden kann, fand ich damals schon dämlich.
Dann hast du dich nie mit der Technik befasst. ;)
Hier im Forum wird immer wieder betont, wie wichtig PLP bei SSDs ist, weil man dadurch deutlich mehr Performance bekommt. Ich habe mich damals schon gefragt, was PLP denn mit Performance zu tun hat. Da ich mich aber nicht auskenne, habe ich die Aussage einfach übernommen. Jetzt bin durch die horrenten Preise zu PLP SSDs wieder über die Frage gestolpert, ob ich denn wirklich PLP brauche. Wenn man im Internet danach sucht, findet man bei einigen SSD-Anbietern immer wieder die gleiche Erklärung: PLP-SSDs bringen zusätzliche Kondensatoren mit, die bei einem Stromausfall den flüchtigen Cache auf die Speicherzellen schreiben. Nun stellt sich mir aber weiterhin die Frage, was das mit Performance zu tun hat. So weit ich es noch im Kopf habe argumentieren, die Vertreter dieser Meinung wie folgt: Raid-Controller oder Raid-Filesysteme wie zfs deaktieren den Festplatten-Cache, damit gesichert ist, dass die Daten wirklich sicher geschrieben wurden. Wenn eine Platte aber PLP hat, wird der Cache nicht deaktiviert und darum ist die Performance besser. Siehe:https://www.reddit.com/r/storage/co...gain_of_plp_powerlossprotection_drives/?tl=de
Berichtigt mich, wenn ich es falsch wieder gebe! Meine Recherche ergab ein anderes Ergebnis. Da dieses Thema immer bei zfs aufkam, habe ich mich auch auf zfs konzentriert.
Leider kann ich es nicht nachprüfen, da ich hier keine zfs installation habe, aber die Quelle, die ich gefunden habe, behauptet, das zfs keinen Cache abschaltet, sondern davon ausgeht, dass er an ist und bei Sync-Writes manuelle Flush Commands an das Gerät senden. Siehe:https://serverfault.com/questions/995702/zfs-enable-or-disable-disk-cache/995729#995729

Prüfen kann man den Cache mit:

hdparm -W /dev/sda

Aus- und Einschalten mit:

hdparm -W 1 /dev/sda
hdparm -W 0 /dev/sda

Für mich ergibt das die Schlussfolgerung, dass der Performanceboost nicht mit PLP zu tun hat, sondern einfach der Tatsache geschuldet ist, dass man Enterprise SSDs einsetzt. Die haben eben noch ganz viele Spielerreien verbaut wie größeren Cache, bessere Cachezellen, besseren Controller usw. usf.

Wie kann man nun die Sync-Writes vom zfs noch beschleunigen, wenn man einen SLOG einsetzt oder Full-Flash fährt? Nun schlage ich den Bogen zu meinem Einleitungsthema. Ich beleuchte hier das Thema natürlich nur bezüglich einer professionellen Unternehmensumgebung. Wenn ich einen Server mit 2 Netzteilen und einer USV habe, dann ist der Stromausfall praktisch ausgeschlossen. Warum sollte dann das zfs regelmäßig flushen? Denn wenn es das tut, wartet es auch jedesmal auf die Rückmeldung, ob es passiert ist. Die Latenz des Storage steigt. Wäre es dann nicht sinnvoller diesen Vorgang im zfs zu deaktivieren? Ich denke ja.
Dies macht man indem man einen Paramter setzt (/etc/modprobe.d/zfs.conf).

options zfs zfs_nocacheflush=1
Also ganz einfach. Wir nehmen mal eine TLC SSD (bei QLC wird alles nur schlimmer).
Wenn du deine Daten auf deine SSD schreiben willst, dann müssen 3 Bit auf die Zelle geschrieben werden, was relativ langsam ist.
Daher nutzen Consumer SSDs die TLC Zellen als Cache im SLC Schreibverfahren, also ein Bit pro Zelle. Da du aber nicht nur ein Drittel Kapazität speichern möchtest werden die Daten nachher wieder im TLC Format umkopiert. Das führt zu mehr Verschleiß und ist nicht so schnell wie ein DRAM Cache. Wenn due eine Enterprise SSD hast (alle mit PLP) dann werden die daten im RAM abgelegt und das ACK geht direkt an die Anwendung raus. Danach werden die Daten manchmal auch zusammengefasst, um Zellen nicht zwei mal beschreiben zu müssen, sondern immer komplette Writes pro Zelle durchführen zu können.
Das macht deutlich mehr Durchsatz. Wenn der Server ausgeht oder Abstürzt, wird der Cache mit dem verbleibenden Strom auf Flash Zellen geschrieben.
Ohne PLP kannst du auch den DRAM Cache aktivieren !AUF EIGENE GEFAHR! und wenn dein Server mal ausgeht, ist die Wahrscheinlichkeit für Korrupte daten recht hoch und bei ZFS Raid garantiert. Mit viel Glück kann sich das ZFS selbst heilen, aber darauf würde ich mich nie verlassen.
Dein Argument mit USV und RPS hilft dir nicht wirklich weiter, da du dann garantieren müsstest, dass die USV niemals ausfällt, und die Kommunikation zur USV niemals gestört wird. Das kann keiner garantieren, daher ist das nur eine Erhöhung der Verfügbarkeit des Servers aber kein Schutz für Datenträger.
Man kann auch ohne Probleme ZFS auf Raid Controllern mit Batteriecache betreiben, aber dann musst du ganz genau wissen was du tust und wie jede einzelne Komponente arbeitet. Das können nur ganz wenige, daher die Empfehlung kein Raid Controller mit ZFS.
Ich habe schon solche Setups gebaut, aber ich arbeite seit über 20 Jahren mit Raid Controllern und weiß um die möglichen und wichtigen Einstellungen und Effekte welche man unbedingt beachten muss.

Ich wäre auch imemr ganz vorsichtig mir Reddit oder noch schlimemr serverfault.com. Da habe ich auch schon einigen Bullshit gelesen, wenn du wissen willst wie die Technik funktioniert, dann nimm dir die Dokumentationen der Hersteller und lese dich selbst in das Thema ein.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!