VM gesteigert schädlich für SSD?

[Wanderdüne]

Hallo,

neulich ist mir eine 870 EVO mit Fehlern ausgefallen, vermutlich weil eine suboptimale Firmware die Schreiblast nicht gleichmäßig verteilt hat.

Nun stelle ich mir die Frage, ob nicht das gleiche passiert, wenn man eine VM auf einer SSD installiert. Ich habe hier z.B. WinXP als VBox-Gast auf LinuxMint20.3 als Host mit ext4 auf einer SSD. Zwar kann LM20.3 trimmen, aber die VDI-Datei wird nie als löschbar gekennzeichnet, sodass immer nur innerhalb der einen großen Datei geschrieben und bzw. überschrieben wird.
Ist es nun so, dass auch immer wieder die gleichen physikalischen Zellen beschrieben werden, oder verteilt der SSD-Kontroller die Schreibzyklen trotzdem über alle freien Zellen auf dem Laufwerk?

 

[Holt]

vermutlich weil eine suboptimale Firmware die Schreiblast nicht gleichmäßig verteilt hat.

Hast Du denn kein FW Update ausgeführt? Ab und zu sollte man mal schauen ob es ein FW Update gibt.

Ist es nun so, dass auch immer wieder die gleichen physikalischen Zellen beschrieben werden, oder verteilt der SSD-Kontroller die Schreibzyklen trotzdem über alle freien Zellen auf dem Laufwerk?

Jede SSD sollte Wear Leveling machen und die Schreibzugriffe entsprechend über die NAND Pages so verteilen, dass sie möglichst gleichmäßig abnutzen. Einige behaupten, dass dies bei den Samsung 970 EVO anfangs nicht so gut geklappt hat und dieser Bug dann per FW Update behoben wurde. Keine Ahnung ob dies stimmt, aber sowas kann im Prinzip bei jeder SSD passieren, die Nutzung und das OS haben damit gar nichts zu tun.

 

[Wanderdüne]

Hast Du denn kein FW Update ausgeführt? Ab und zu sollte man mal schauen ob es ein FW Update gibt.

Das FW-Update habe ich erst gemacht, als die SSD schon Fehler erzeugt hat. Die SSD steckte in einem PC, den ich nur ganz selten benutzt habe und ich habe nicht damit gerechnet, dass ein _nicht_ installiertes FW-Update schon nach so geringer Nutzung solche Fehler erzeugt.

Jede SSD sollte Wear Leveling machen und die Schreibzugriffe entsprechend über die NAND Pages so verteilen, dass sie möglichst gleichmäßig abnutzen.

Wie ist das denn im konkreten Fall, also wenn ein OS, dass kein TRIM beherrscht (XP) in einer VM läuft und dabei immer nur innerhalb einer Datei arbeitet? Verteilt die SSD die Schreibzugriffe dann trotzdem über alle freien Zellen? Oder anders gesagt: Ist die logische Position der Daten völlig losgelöst von der physikalischen?

 

[Holt]

Wie ist das denn im konkreten Fall, also wenn ein OS, dass kein TRIM beherrscht (XP) in einer VM läuft und dabei immer nur innerhalb einer Datei arbeitet?

Da spielt TRIM sowieso keine Rolle, da dies ja nur aktiv ist, wenn eine Datei gelöscht wird, nicht wenn sie überschrieben wird, egal ob ganz oder teilweise. Dann erfährt der Controller ja sowieso durch das Überschreiben, dass die alten Daten nun ungültig geworden sind. Ob TRIM bei Virtualisierung, wo die Platte der VM dann "eine" Datei (auch wenn sie ggf. auf mehrere kleinere Dateien aufgeteilt) ist, überhaupt geht, ist noch eine andere Frage, die ich zwar nicht mit Sicherheit für jede Virtualisierungslösung beantworten kann, Aber ich bezweifel es eher als das ich es annehmen würde. Das müsste man mal ausprobieren, z.B. indem man in der VM eine große Datei erstellt, die Datei(en) die deren Laufwerk ist, dann komprimiert um zu sehen wie groß sie dann noch ist. Danach löscht man diese Datei der VM, ohne sie extra zu überschreiben, schon gar nicht mit Nullen und nach einiger Wartezeit die Komprimierung wiederholt. Wenn dann beim zweiten mal die komprimierte Datei deutlich kleiner ist, dann sollte TRIM funktioniert haben, denn die meisten SSD liefern ja beim Auslesen getrimmter Adressen Nullen zurück. Es darf natürlich keine Verschlüsselung auf dem Host oder der VM aktiv sein.

Verteilt die SSD die Schreibzugriffe dann trotzdem über alle freien Zellen?

Sollte sie, die SSD weiß ja nicht, was für Schreibzugriffe es sind. SSDs (und auch HDDs) bieten einen bestimmten, linearen Adressraum von LBA 0 bis irgendwas an, meist 512 Byte pro LBA und diesen in Partitionen, Ordner und Dateien zu unterteilen, macht dann das Betriebssystem, davon weiß eine SSD nichts. Die SSDs bekommen nur Befehle ab LBA x die folgenden y LBAs zu lesen, zu schreiben oder zu trimmen. Was für Daten das sind, ob es die Partitionstabelle, Metadaten des Filesystem oder Teile einer Datei ist, davon weiß eine SSD oder auch eine HDD nichts.

Ist die logische Position der Daten völlig losgelöst von der physikalischen?

Meinst Du innerhalb der SSD? Ja, deshalb haben SSDs ja auch immer eine Mappingtabelle, denn da steht drin, wo die Daten die unter einer bestimmten logischen Adresse (LBA) dann im NAND stehen. Bei HDDs rechnet der Controller jeden LBA fest auf immer die gleiche Positions bzgl. Zylinder, Spur und Kopf um, außer er wurde als defekt ausrangiert und durch einen Reservesektor ersetzt. Dies geht bei SSDs aber schon deswegen nicht, weil man die NAND Pages nicht direkt überschreiben kann, sondern erst den ganzen NAND Block zu dem diese Page gehört, löschen muss und ein NAND Block hat typischerweise so 512 oder auch 1024 NAND Pages die meist jeweils 16k oder 32k groß sind. Da man vor dem Löschen alle gültigen Daten der andere Pages des Blocks lesen und danach zurückschreiben müsste, wären Schreibvorgänge nicht nur sehr langsam, sondern die NANDs würden auch sehr schnell verschleißen, wollte man bei einer SSD wie bei einer HDD die Daten immer in der gleichen Stelle im NAND ablegen. Deshalb schreiben die Controller neue Daten immer noch freie NAND Pages und ändern eben den Eintrag in der Mappingtabelle für den LBA auf die neue NAND Adresse und markieren die alten Daten als ungültig.