Powerloss Protection (PLP) Mythos

Status
Not open for further replies.
F

floh8

Renowned Member
Jul 27, 2021
1,066
119
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.
 
floh8 said:
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.
Click to expand...
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: IsThisThingOn, DSSTNY, Retro1982 and 2 others
floh8 said:
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.
Click to expand...
Dann hast du dich nie mit der Technik befasst. ;)
floh8 said:
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
Click to expand...
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 immer 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.
 
Last edited:
  • Like
Reactions: Retro1982, UdoB and Johannes S
Also ihr seid ja krass drauf. Ich dachte, ich bin verrückt, aber ihr topt das ja nochmal. Zu welchen Zeiten schreibt ihr denn noch hier im Forum?

Also, euren Reaktionen entnehme ich, das ihr den meisten meiner Aussagen zustimmt. Viel findet man leider nicht dazu. Gerade auch die Hersteller werden sich natürlich darüber schön bedeckt halten, wie sie es im Detail lösen, was ja wegen Konkurrenzdenken nachvollziehbar ist. In meinem Post hätte ich nochmal eine kurze Zusammenfassung schreiben sollen, damit man meine Aussagen besser nachvollziehen kann. Deshalb mache ich das jetzt nochmal:

1. Nutze immer Enterprise Class SSDs/HDDs
2. man kann auf PLP verzichten in prof. Enterprise Umgebungen
3. deaktiviere das Flushen von zfs bei Sync-Writes
4. PLP hat nichts mit Performance zu tun
5. zfs deaktiviert nicht den SSD Cache

Zu 2. will ich nochmal näher eingehen.
Wenn ich von Enterprise Umgebungen schreibe, dann meine ich das die Server oder Shelfs 2 Netzteile haben und das jedes Netzteil an eine andere USV angeschlossen ist. Das nennt man redundante USV-Lösung. Kennt ihr bestimmt auch. Damit wäre dann ein Stromausfall fast ausgeschlossen.

Gehen wir mal die Fehlermöglichkeiten durch (ohne PLP):

1. Netzteil fällt aus -> unproblematisch, da ein 2. Netzteil da ist
2. USV fällt aus -> unproblematisch, da 2. USV da ist
3. Motherboard oder Backplane fällt aus -> schlecht, Daten wären fehlerhaft
4. HBA Controller fällt aus -> schlecht, da kein abschließender Flushbefehl gesendet werden kann (??)
5. Server hängt -> wenn er hart ausgeschaltet werden muss, dürfte kurzzeitig der Strom weg sein

Zu 3.: Und nun die Gretschenfrage: Wie oft ist euch schon ein Motherboard oder eine Backplane kaputt gegangen? Das passiert äußerst selten, da man ja Enterprise Hardware einsetzt. Noch seltener ist, wenn ein Feuer ausbricht, was dann auch SSDs mit PLP zerstören würde. Für diese Fälle hat man ja aber eine Datensicherung.

Zu 4.: Ich denke, dass die SSD von sich aus in einem bestimtmen Intervall die Daten aus dem Cache zu den Speicherzellen sendet.

Zu 5.: wie 4.

Es ist also wie Falk bemerkt eine Philosophiefrage wie paranoid man ist und wie viel Geld man ausgeben will. Ich bin eher der sparsame Typ, der trotzdem auf Performance und Ausfallsicherheit steht. Wenn man allerdings die gebrauchten SSDs so ansieht, haben die meisten PLP, auch wenn dies öfter auf den Verkausportalen gar nicht angegeben ist.
 
Last edited:
floh8 said:
Also ihr seid ja krass drauf. Ich dachte, ich bin verrückt, aber ihr topt das ja nochmal. Zu welchen Zeiten schreibt ihr denn noch hier im Forum?

Also, euren Reaktionen entnehme ich, das ihr den meisten meiner Aussagen zustimmt. Viel findet man leider nicht dazu. Gerade auch die Hersteller werden sich natürlich darüber schön bedeckt halten, wie sie es im Detail lösen, was ja wegen Konkurrenzdenken nachvollziehbar ist. In meinem Post hätte ich nochmal eine kurze Zusammenfassung schreiben sollen, damit man meine Aussagen besser nachvollziehen kann. Deshalb mache ich das jetzt nochmal:

1. Nutze immer Enterprise Class SSDs/HDDs
2. man kann auf PLP verzichten in prof. Enterprise Umgebungen
Click to expand...
Kannst du nicht, da per Design alle Enterprise SSDs PLP haben. ;)
floh8 said:
3. deaktiviere das Flushen von zfs bei Sync-Writes
4. PLP hat nichts mit Performance zu tun
Click to expand...
Oh doch, da die SSDs mehr RAM als Cache haben und diesen als Schreibcache nutzen.
floh8 said:
5. zfs deaktiviert nicht den SSD Cache

Zu 2. will ich nochmal näher eingehen.
Wenn ich von Enterprise Umgebungen schreibe, dann meine ich das die Server oder Shelfs 2 Netzteile haben und das jedes Netzteil an eine andere USV angeschlossen ist. Das nennt man redundante USV-Lösung. Kennt ihr bestimmt auch. Damit wäre dann ein Stromausfall fast ausgeschlossen.
Click to expand...
Das PLP hat nix mit der USV Absicherung zu tun, das sind zwei ganz verscheidene Ebenen.
floh8 said:
Gehen wir mal die Fehlermöglichkeiten durch (ohne PLP):

1. Netzteil fällt aus -> unproblematisch, da ein 2. Netzteil da ist
2. USV fällt aus -> unproblematisch, da 2. USV da ist
3. Motherboard oder Backplane fällt aus -> schlecht, Daten wären fehlerhaft

Und nun die Gretschenfrage: Wie oft ist euch schon ein Motherboard oder eine Backplane kaputt gegangen? Das passiert äußerst selten, da man ja Enterprise Hardware einsetzt. Noch seltener ist, wenn ein Feuer ausbricht, was dann auch SSDs mit PLP zerstören würde. Für diese Fälle hat man ja aber eine Datensicherung.
Click to expand...
Es gibt noch ganz viel mehr Fehlerquellen, du betrachtest nur einen Teil der Hardware.
Ein Server hat ein Blue/Red/Purple Screen. CPU Defekt, HBA hat einen Fehler, ganz oft einen Hard Lock, wo nur ein Reboot hilft. Und noch einige selktene Problemchen.
Fast alle Enterprise Storagesysteme nutzen ein Batterie/USV System um einen großen RAM Writecache zu halten, aber der wird auch noch gespiegelt auf zwei Controller. Damit holt das System mit dem dicken RAM viel Performance aus HDDs und SSDs raus. PLP habe die Enterprise SSDs in diesen Storagesystemen trotzdem, weil man damit deutlich weniger Zellverschleiß und bessere Schreibperformance in den SSds hat.
Klar kannst du deinen Server mit USV und RPS absichern und dann auf deinen günstigen Consumer SSDs den RAM als schreibcache nutzen, aber die Wahrscheinlichkeit, dass du dein Backup tatsächlich mal brauchst, erhöht sich deutlich.
floh8 said:
Es ist also wie Falk bemerkt eine Philosophiefrage wie paranoid man ist und wie viel Geld man ausgeben will. Ich bin eher der sparsame Typ, der trotzdem auf Performance und Ausfallsicherheit steht. Wenn man allerdings die gebrauchten SSDs so ansieht, haben die meisten PLP, auch wenn dies öfter gar nicht angegeben ist.
Click to expand...
Bei Enterprise SSDs wird PLP nicht angegeben, da es dort selbstverständlich ist.
 
  • Like
Reactions: Johannes S
Falk R. said:
Kannst du nicht, da per Design alle Enterprise SSDs PLP haben.
Click to expand...
Glaub ich nicht, da viele HDDs mit Cache auch kein PLP haben. Wie ich geschrieben haben, sind es bei den SSDs weitaus weniger. Ich denke, das wird auch zu einem quasi Standard.
Falk R. said:
Oh doch, da die SSDs mehr RAM als Cache haben und diesen als Schreibcache nutzen.
Click to expand...
Das ist aber PLP unabhängig.
Falk R. said:
Das PLP hat nix mit der USV Absicherung zu tun, das sind zwei ganz verscheidene Ebenen.
Click to expand...
Das denke ich nicht. Dies ist auch auf Herstellerseite klar formuiert.
Falk R. said:
Es gibt noch ganz viel mehr Fehlerquellen, du betrachtest nur einen Teil der Hardware.
Click to expand...
Bevor ich deinen Post gelesen habe, hatte ich noch weitere Fehlerquellen ergänzt. CPU steht gleich mit Punkt 5.
Falk R. said:
Bei Enterprise SSDs wird PLP nicht angegeben, da es dort selbstverständlich ist.
Click to expand...
Es haben leider nicht alle Enterprise SSDs PLP. Wenn dem so wäre, wäre mein Post ja sinnlos.
 
floh8 said:
Glaub ich nicht, da viele HDDs mit Cache auch kein PLP haben. Wie ich geschrieben haben, sind es bei den SSDs weitaus weniger. Ich denke, das wird auch zu einem quasi Standard.
Click to expand...
HDDs funktionieren auf einem ganz anderen Prinzip und können nicht so viel davon profitieren, deshalb gibt es da keinen PLP.
floh8 said:
Das ist aber PLP unabhängig.

Das denke ich nicht. Dies ist auch auf Herstellerseite klar formuiert.
Click to expand...
Welcher Hersteller?
floh8 said:
Bevor ich deinen Post gelesen habe, hatte ich noch weitere Fehlerquellen ergänzt. CPU steht gleich mit Punkt 5.

Es haben leider nicht alle Enterprise SSDs PLP. Wenn dem so wäre, wäre mein Post ja sinnlos.
Click to expand...
Zeig mir mal eine einzige Enterprise SSD ohne PLP. Ich habe schon mit schnellem Flash Speicher gearbeitet bevor es NVMe gab. Damals gab es etwas Properitäres namens Fusion IO. Bei denen habe ich auf einer Schulung ganz tief unter die Haube schauen dürfen und nur das Protokoll NVMe hat die Firma unwirtschaftlich gemacht, an der grundlegenden Technik hat sich nix geändert.
Die letzten Enterprise SSDs ohne PLP welche ich gesehen habe waren vor 15 Jahren die SLC und MLC Laufwerke. Das heute TLC Standard ist, haben wir der PLP Technik zu verdanken.
 
  • Like
Reactions: Johannes S and Retro1982
Du uebersiehst hier leider ein Detail. Wie aaron schon schon geschrieben hat, liegt der Unterschied in den sync writes. Diese sind zum Beispiel logs (flush nach jedem Eintrag), die meisten writes von Datenbanken und ja ZFS verwendet auch eine Menge sync writes.

Ohne PLP (und ohne missbehaving Firmware) muss jeder dieser sync writes auf den Flash geschrieben werden. Da beim Schreiben zumindest ein Block geloescht werden muss (bei vielen SSDs auch mehre Blocks, kommt auf den internen Aufbau an), wird ein kompletter Block (128KB oder 256KB, moderne SSDs verwende auch groessere Block sizes) gelesen, die paar Bytes an Log upgedated und dann der Block wieder geschrieben. Danach kann erst das ack fuer den sync write an das Betriebsystem zurueck gegeben werden. Wenn zum Beispiel 1K mit einem sync write geschrieben wird, hast du hier schon eine write amplification am Flash von zumindest 128.

Mit PLP kann der sync write im RAM der SSD gecached werden und sofort ein ACK an das OS zurueckgeben werden. Hier wird vorerst einmal gar nichts auf den Flash geschrieben. Nun kann die SSD soviele sync writes cachen, bis im Idealfall ein kompletter Block an Daten gecached ist und dieser wird dann einmalig auf den Flash geschrieben. Im Idealfall hast du hier eine write amplification auf dem Flash von 1.

Wenn nun das Filesystem (zum Beispiel ZFS) selbst mit sync writes arbeitet kannst du dir vorstellen wieviel unnoetige writes durch die fehlende PLP (und damit die Moeglichkeit sync writes zu cachen) auf dem Flash landen, da die SSD diese writes erst acken kann wenn die Daten tatsaechlich auf dem Flash geschrieben sind.

Also zusammengefasst, erst mit PLP koennen sync writes im RAM der SSD gecached und zusammengefasst werden, ansonst muss immer auf den Flash geschrieben werde, was eine hohe write amplification nachsich zieht (bei schon schlechten TBW von consumer SSDs im vergleich zu Enterprise SSDs) und eine wesentlich schlechtere Performance aufweist.
 
  • Like
Reactions: Johannes S and Falk R.
boisbleu said:
Und so sieht das dann aus, hier beispielhaft eine Micron 5300 Pro mit 960GB (also die "kleine" mit 2.63PB TBW).
Click to expand...
Danke, meine hab ich noch nicht aufgeschraubt. Dass sie hier wirklich kleine radiale Elkos ins Gehäuse packen, finde ich schon ein wenig amüsant.
Meistens, gerade auch bei m2 NVMEs sind dann doch SMD Varianten aufgelötet.
 
  • Like
Reactions: Johannes S
  • Like
Reactions: Johannes S
Nettes Bild, aber hilft dir nicht bei deiner Argumentation.
Retro1982 said:
Du uebersiehst hier leider ein Detail. Wie aaron schon schon geschrieben hat, liegt der Unterschied in den sync writes. Diese sind zum Beispiel logs (flush nach jedem Eintrag), die meisten writes von Datenbanken und ja ZFS verwendet auch eine Menge sync writes.

Ohne PLP (und ohne missbehaving Firmware) muss jeder dieser sync writes auf den Flash geschrieben werden. Da beim Schreiben zumindest ein Block geloescht werden muss (bei vielen SSDs auch mehre Blocks, kommt auf den internen Aufbau an), wird ein kompletter Block (128KB oder 256KB, moderne SSDs verwende auch groessere Block sizes) gelesen, die paar Bytes an Log upgedated und dann der Block wieder geschrieben. Danach kann erst das ack fuer den sync write an das Betriebsystem zurueck gegeben werden. Wenn zum Beispiel 1K mit einem sync write geschrieben wird, hast du hier schon eine write amplification am Flash von zumindest 128.

Mit PLP kann der sync write im RAM der SSD gecached werden und sofort ein ACK an das OS zurueckgeben werden. Hier wird vorerst einmal gar nichts auf den Flash geschrieben. Nun kann die SSD soviele sync writes cachen, bis im Idealfall ein kompletter Block an Daten gecached ist und dieser wird dann einmalig auf den Flash geschrieben. Im Idealfall hast du hier eine write amplification auf dem Flash von 1.

Wenn nun das Filesystem (zum Beispiel ZFS) selbst mit sync writes arbeitet kannst du dir vorstellen wieviel unnoetige writes durch die fehlende PLP (und damit die Moeglichkeit sync writes zu cachen) auf dem Flash landen, da die SSD diese writes erst acken kann wenn die Daten tatsaechlich auf dem Flash geschrieben sind.

Also zusammengefasst, erst mit PLP koennen sync writes im RAM der SSD gecached und zusammengefasst werden, ansonst muss immer auf den Flash geschrieben werde, was eine hohe write amplification nachsich zieht (bei schon schlechten TBW von consumer SSDs im vergleich zu Enterprise SSDs) und eine wesentlich schlechtere Performance aufweist.
Click to expand...
Das ist einfach falsch. Wenn das so wäre, würden ja Consumer SSDs bei sync-writes immer langsam sein, sind sie aber nicht. Sie sind 'ne Weile schnell und dann brechen sie ein, wie wir ja alle wissen. Du und Falk ihr könnt aber gern mal Quellen eurer Weisheit posten, wenn ihr es schon besser wißt als das Internet, die SSD-Hersteller & Co, damit wir alle erleuchtet werden. Es sei vorab angemerkt, das ein Zauberspiegel bei euch zu Hause nicht als Quelle gilt. :cool:
Falk R. said:
HDDs funktionieren auf einem ganz anderen Prinzip und können nicht so viel davon profitieren, deshalb gibt es da keinen PLP.
Click to expand...
Und wie es die gibt. Das Problem ist ja auch ganz genau das Gleiche wie bei den SSDs. Da ist kein Unterschied für das prinzipielle Ziel. Volatiler RAM muss geschützt werden. Beispiele? Hier bitte:

ABER wir schweifen ab. In diesem Thread geht es darum, ob PLP für Performance zuständig ist und ob man PLP unbedingt braucht.

Antwort: PLP ist nur für die Datenintegrität zuständig und nicht für Performance. Das kann man überall nachlesen. 2 Herstellerlinks habe ich oben schon angegeben. Hier sind weitere:
Ein Hardwareverkäufer (ganz unten): https://www.servershop24.de/komponenten/festplatten/sas/ssds/
Ein IT-Dienstleister: https://www.thomas-krenn.com/de/wiki/SSD_Power_Loss_Protection
Ein Storageanbieter: https://www.pnpstorage.com/blogs/ssd-2/the-importance-of-plp-in-enterprise-ssds

Braucht man nun PLP unbedingt? Meiner Meinung nach nicht undedingt, wenn man einen professionellen Storage baut (2 Node+alles redundant oder eine Replizierung). Da dann alles so abgesichert ist, dass nur der Ausfall einer Backplane ein Risiko darstellt, wenn man z.B. ein Storage mit geteilten Shelfs (JBODs) implementiert. Bei meiner Recherche hat sich allerdings ergeben, dass nahezu fast alle Enterprise SSDs PLP haben. Selbst ältere gebrauchte SSDs (ich habe mal nur die 2,5", 12Gbit/s angeschaut) bringen alle PLP mit. Man muss sich darüber also keine Gedanken machen.
Hier gebe ich noch einen Hinweis, falls ihr bei geizhals schaut oder bei Servershop24 kaufen wollt. Die Angaben sind im hohen Maße ungenau. Schaut immer nochmal beim Hersteller, ob PLP drin ist oder nicht.
 
floh8 said:
Nettes Bild, aber hilft dir nicht bei deiner Argumentation.

Das ist einfach falsch. Wenn das so wäre, würden ja Consumer SSDs bei sync-writes immer langsam sein, sind sie aber nicht. Sie sind 'ne Weile schnell und dann brechen sie ein, wie wir ja alle wissen.
Click to expand...
Hättest du meine Posts gelesen wüsstest du auch warum. Nochmal zur Erinnerung: Consumer SSDs nutzen ihre TLC/QLC Zellen im SLC Schreibmodus als Cache. (es wird nur ein Zustand pro Zelle statt 3 Zustände bei TLC geändert) Der ist aber limitiert, da du sonst die SSD sehr schnell füllen würdest und das umkopieren würde gar nicht nachkommen. Genau diesen Effekt sparst du dir mit dem DRAM Cache.
floh8 said:
Du und Falk ihr könnt aber gern mal Quellen eurer Weisheit posten, wenn ihr es schon besser wißt als das Internet, die SSD-Hersteller & Co, damit wir alle erleuchtet werden. Es sei vorab angemerkt, das ein Zauberspiegel bei euch zu Hause nicht als Quelle gilt. :cool:
Click to expand...
Da anscheinend dein google defekt ist, hier mal eine Quelle von einem Hersteller: https://de.transcend-info.com/embedded/technology/slc-mode
floh8 said:
Und wie es die gibt. Das Problem ist ja auch ganz genau das Gleiche wie bei den SSDs. Da ist kein Unterschied für das prinzipielle Ziel. Volatiler RAM muss geschützt werden. Beispiele? Hier bitte:

ABER wir schweifen ab. In diesem Thread geht es darum, ob PLP für Performance zuständig ist und ob man PLP unbedingt braucht.

Antwort: PLP ist nur für die Datenintegrität zuständig und nicht für Performance. Das kann man überall nachlesen. 2 Herstellerlinks habe ich oben schon angegeben. Hier sind weitere:
Click to expand...
Naja dann frag mal alle die Erfahrung in der Praxis haben. Klar kann man auch Performance ohne Datenintigrität haben, aber wer will das denn?
floh8 said:
Ein Hardwareverkäufer (ganz unten): https://www.servershop24.de/komponenten/festplatten/sas/ssds/
Ein IT-Dienstleister: https://www.thomas-krenn.com/de/wiki/SSD_Power_Loss_Protection
Ein Storageanbieter: https://www.pnpstorage.com/blogs/ssd-2/the-importance-of-plp-in-enterprise-ssds

Braucht man nun PLP unbedingt? Meiner Meinung nach nicht undedingt, wenn man einen professionellen Storage baut (2 Node+alles redundant oder eine Replizierung). Da dann alles so abgesichert ist, dass nur der Ausfall einer Backplane ein Risiko darstellt, wenn man z.B. ein Storage mit geteilten Shelfs (JBODs) implementiert. Bei meiner Recherche hat sich allerdings ergeben, dass nahezu fast alle Enterprise SSDs PLP haben. Selbst ältere gebrauchte SSDs (ich habe mal nur die 2,5", 12Gbit/s angeschaut) bringen alle PLP mit. Man muss sich darüber also keine Gedanken machen.
Hier gebe ich noch einen Hinweis, falls ihr bei geizhals schaut oder bei Servershop24 kaufen wollt. Die Angaben sind im hohen Maße ungenau. Schaut immer nochmal beim Hersteller, ob PLP drin ist oder nicht.
Click to expand...
Noch mal kurz zu den HDDs mit PLP, das wird vor allem nur bei den ganz großen HDDs genutzt, um diese etwas zu beschleunigen und da die HDDs eh schon etwas teurer sind, fällt der PLP nicht mehr so ins Gewicht. Datenintegrität hast du aber trotzdem bei allen HDDs.
 
  • Like
Reactions: Johannes S and Retro1982
floh8 said:
Nettes Bild, aber hilft dir nicht bei deiner Argumentation.

Das ist einfach falsch. Wenn das so wäre, würden ja Consumer SSDs bei sync-writes immer langsam sein, sind sie aber nicht. Sie sind 'ne Weile schnell und dann brechen sie ein, wie wir ja alle wissen. Du und Falk ihr könnt aber gern mal Quellen eurer Weisheit posten, wenn ihr es schon besser wißt als das Internet, die SSD-Hersteller & Co, damit wir alle erleuchtet werden. Es sei vorab angemerkt, das ein Zauberspiegel bei euch zu Hause nicht als Quelle gilt. :cool:
Click to expand...

Sind sie auch, eine der Quellen: https://www.percona.com/blog/fsync-performance-storage-devices/ um jetzt alle wieder auszugraben ist mir die Zeit zu schade. Am besten du probierst es selbst aus, in dem Link ist auch ein kleines python script das eine Reihe von synced writes ausloest.
Aber ganz ehrlich, wenn du meinst dass es egal is ob mit oder ohne PLP und es keinen Unterschied gibt, dann verwende halt Consumer SSDs aber wunder dich spaeter nicht wenn sie wie Fliegen sterben.

Von was du redest ist der SLC cache, das hat (ausser die firmware tricks) nur bedingt mit synced writes zu tun. Egal ob jetzt mit oder ohne SLC cache die Daten muessen bei synced writes immer am Flash landen da sie ohne PLP nicht im RAM gespeichert werden duerfen.
 
Last edited:
  • Like
Reactions: Johannes S and Falk R.
Da ihr beiden Scharchnasen wohl über Consumer SSDs schreiben wollt, sucht euch einen anderen Thread, wo ihr eurer Palaber loswerden könnt. In diesem Thread geht es um Enterprise SSDs und HDDs und PLP. Lest mal genauer meine Posts und schreibt dann was Konstruktives. Spammen könnt ihr in euer Muttiheft. Alter sind die gagga.
 
Last edited:
floh8 said:
Da ihr beiden Scharchnasen wohl über Consumer SSDs schreiben wollt, sucht euch einen anderen Thread, wo ihr eurer Palaber loswerden könnt. In diesem Thread geht es um Enterprise SSDs und HDDs und PLP. Lest mal genauer meine Posts und schreibt dann was Konstruktives. Spammen könnt ihr in euerm Muttiheft. Alter sind die gagga.
Click to expand...
Ich wuerde dich bitten Sachlich zu bleiben, das sind alle Anderen auch.

Der Unterschied zwischen Enterprise SSDs und Consumer SSDs ist ja nur die PLP, vielleicht etwas mehr RAM und ein etwas bessere Flash, klaer mich auf wenn dem nicht so ist.

Aber ich habe den Eindruck es geht dir gar nicht darum zu verstehen was mit PLP und der sich daraus ergebenden Moeglichkeit synced writes im RAM schon zu bestaetigen fuer Vorteile ergeben...
 
Last edited:
  • Like
Reactions: Johannes S and Falk R.
Guten Morgen,

ihr vergesst aber nicht die TBW, die Consumer von Enterprise unterscheiden?

Nur mal ein kleines Beispiel: die Samsung 860 EVO 1TB SATA SSD (kam 2018 auf dem Markt) schafft 600TB, die oben gezeigte (ReadIntensive) Micron 5300 Pro kommt auf 2,6PB und die Micron 5300 MAX kommt auf 8,76PB - jeweils in der 960GB Variante.

Da stellt sich mir gar nicht die Frage, was ich in Geschäftsumgebungen einsetze - selbst wenn ich mir vorher schon sicher bin, dass diese Größenordnungen an Schreibleistung gar nicht erreicht werden. Aber wenn ich z.B. eine Micron 5400 MAX mit 3,8TB einsetze, dann liegen wir schon bei sagenhaften 24,53PB TBW. Das ist für mich Enterprise!

Ich sehe PLP auch nur als Absicherung und ich lese auch nirgendwo etwas anderes. Es kann ja auch mal Netzteil durchknallen und das Mainboard zerstören. Dann wäre die USV was die Stromversorgung geht komplett außen vor. Oder jemand tauscht im laufenden Betrieb die BIOS-Batterie und lässt sie fallen. :oops:

Hier ein kleines WhitePaper zum Thema:

https://www.micron.com/content/dam/.../ssd-power-loss-protection-white-paper-lo.pdf

Cheers
 
  • Like
Reactions: Johannes S and Falk R.
Status
Not open for further replies.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back