Funktioniert der Abnutzungsgrad normalerweise ohne TRIM?

1129
UTF-8

Egal, ob es sich um UEFI, Telefone oder SSDs handelt, Samsung ist anscheinend nicht besonders gut darin, Standards umzusetzen. Leider habe ich vor einem Jahr eine Samsung SSD 840 PRO Series SSD für meinen Laptop gekauft, die ich seitdem verwende (dies war, bevor alle Informationen über ihre nicht standardkonformen Implementierungen veröffentlicht wurden). Es ist eine wirklich schöne SSD, mit Ausnahme des asynchronen Trim, das nicht richtig funktioniert, dh Daten löscht, die nicht gelöscht werden sollen. Aus diesem Grund verwendet Linux kein Trim auf dem Gerät, sodass die Daten der Benutzer nicht verloren gehen (was vor dem Deaktivieren des Trim auf bestimmten Samsung SSD-Modellen geschah).

Weil ich diese SSD schon öfter benutzt habe: Wie stark wirkt sich ein deaktiviertes Trimmen auf die Fähigkeit der SSD aus, das Abnutzungsniveau zu erreichen?

Ich habe keine besonders guten und zuverlässigen Informationen zu den verschiedenen Attributen von SMART-Daten finden können. Hauptsächlich Personen und Artikel, die sich nach wenigen Sätzen grundsätzlich selbst erraten und widersprechen.

Dieser Wikipedia- Artikel sagt:

Jeder Laufwerkhersteller definiert einen Satz von Attributen und legt Schwellenwerte fest, ab denen Attribute im normalen Betrieb nicht überschritten werden dürfen. Jedes Attribut hat einen Rohwert, dessen Bedeutung vollständig vom Laufwerkhersteller abhängig ist (entspricht aber häufig Zählungen oder einer physikalischen Einheit, wie Grad Celsius oder Sekunden), einem normalisierten Wert, der von 1 bis 253 reicht (wobei 1 das ist (schlechtester Fall und 253 steht für den besten Wert) und ein schlechtester Wert, der den niedrigsten aufgezeichneten normalisierten Wert darstellt. Der anfängliche Standardwert für Attribute ist 100, kann jedoch je nach Hersteller variieren.

Zunächst einmal: Wie relevant ist dies angesichts der Überschrift "Bekannte ATA SMART-Attribute"? Trifft es auf SSDs zu, die über SATA angeschlossen sind?

Warum liegen die Werte zwischen 1 und 253? Was ist mit 0, 254 und 255? Werden sogar Werte über 100 verwendet?

Die SMART-Daten meiner SSD sehen folgendermaßen aus (entsprechend gnome-disks):

Es gibt keine Werte größer als 100.

Ich habe viele externe Festplatten, aber nur diese eine SSD (die intern ist), so dass ich die SMART-Daten nicht mit denen anderer SSDs vergleichen kann, von denen ich weiß, wie viel sie verbrauchen. Ich nehme jedoch an, dass der Rohwert der Verschleißstufe der SSD 245 bedeutet, dass die Speicherzellen der SSD im Durchschnitt 245 mal geschrieben wurden. Bitte sagen Sie mir, ob dies richtig ist, ob auch Lesevorgänge zählen, ob es sich nur um das 245-fache des angegebenen Speicherplatzes (256 GB) oder um den angegebenen Speicherplatz + den reservierten Speicherplatz handelt (um ausgefallene Teile zu ersetzen).

Bedeutet der normalisierte Verschleißwert meiner SSD 93, dass sie während ihrer gesamten Lebensdauer fast zwei Drittel beträgt () oder dass sie ziemlich schlecht ist ()?

Und eine letzte Frage: Warum deaktiviert Linux das Trimmen insgesamt mit diesen SSDs, wenn nur asynchrones Trimmen Datenverlust verursacht?

Ausgabe von $ sudo smartctl /dev/sda -a: http://pastebin.com/Prf7NzwN

Zugehörige Frage, die von mir als Antwort auf die Diskussion in Kommentaren erstellt wurde: https://unix.stackexchange.com/questions/333635/enabling-synchronous-trim-only

0
Kannst du die Ausgabe von `smartctl / dev / sda` posten? (Desinfektion der Seriennummern nach Bedarf.) bwDraco vor 7 Jahren 0
@ bwDraco Ich habe es der Frage hinzugefügt. UTF-8 vor 7 Jahren 0

1 Antwort auf die Frage

0
bwDraco

Um die Kernfrage zu beantworten, ja, aber Ihre Festplatte leidet unter einer suboptimalen Leistung. ( Ich habe die SMART-Daten bei GitHub Gist neu veröffentlicht. )

Ihre SMART-Statistiken zeigen an, dass Sie 21,5 TiB auf das Laufwerk geschrieben haben (insgesamt 46248065971 LBAs, jeweils 512 Byte). Dies sind 86 Schreibvorgänge für Host-Schreibvorgänge (bei 256 GiB rohem NAND). Sie haben jedoch erwähnt, dass das zugrunde liegende NAND des Laufwerks über 245-mal geschrieben wurde. Mit anderen Worten, das Laufwerk hat fast dreimal die Daten geschrieben, die Sie tatsächlich an das Laufwerk gesendet haben. Dies wird als Schreibverstärkung bezeichnet.

Um zu erklären, was los ist, werde ich einige der Inhalte in einer anderen Antwort zusammenfassen, die ich geschrieben habe. NAND-Flash-Speicher bestehen aus einer Reihe von Blöcken mit jeweils mehreren Seiten. Daten können auf einzelne Seiten geschrieben werden, müssen aber in ganzen Blöcken gelöscht werden, und Seiten, die Daten enthalten, können erst nach dem Löschen neu geschrieben werden. Um das unnötige Löschen von Blöcken und das Umschreiben von Daten zu vermeiden, verteilen SSDs Schreibvorgänge auf verschiedene Blöcke und markieren die alten Daten als ungültig. Das Laufwerk versucht zu vermeiden, Blöcke zu löschen, bis alle Seiten in jedem Block als ungültig markiert sind. Dies führt dazu, dass nicht genügend freie Seiten zur Verfügung stehen. In diesem Fall muss das Laufwerk Blöcke löschen, die gültige Daten enthalten, und diese Daten an anderer Stelle erneut schreiben, um Speicherplatz für neue Daten freizugeben. Da dies bedeutet, dass die gleichen Daten mehr als einmal in das darunterliegende NAND geschrieben werden, wird dieses unerwünschte Verhalten als Schreibverstärkung bezeichnet .

Das Fehlen von TRIM bedeutet, dass das Laufwerk gelöschte Daten als gültig behandelt und den für das Laufwerk verfügbaren freien Speicherplatz reduziert. Das Laufwerk verhält sich letztendlich so, als wäre es voll, selbst wenn es nicht ist.

Um Ihre Frage so zu beantworten, wie sie geschrieben wurde, sollte sich das Laufwerk ordnungsgemäß verschleißenSchreibvorgänge über das NAND so weit wie möglich verteilen. Wenn ich Samsung kenne, wäre ich sehr überrascht, wenn ihre Algorithmen dies auf einer vollen Festplatte nicht richtig machen würden. Es schreibt jedoch ständig neue Daten, die bereits geschrieben wurden, was die Leistung beeinträchtigt und die Ausdauer verringert. Da TRIM nicht verfügbar ist, besteht die beste Wette darin, das Laufwerk zu hoch bereitzustellen oder weniger als die volle Kapazität (256 GB) für Partitionen (z. B. 200 GB) zuzuweisen. Sie müssen das Laufwerk jedoch sicher löschen, damit dies funktioniert. Das bedeutet, dass zunächst alle Daten gesichert und anschließend wiederhergestellt werden müssen. Angesichts der begrenzten Kapazität des Laufwerks bin ich auch nicht sicher, ob Sie die Größe der Partition sogar sinnvoll reduzieren können, ohne dass Ihnen der Speicherplatz ausgeht.

Für Ihre Interpretation der SMART-Daten:

  • Ja, bei Samsung und vielen anderen SSDs ist der Rohwert für die Verschleißnivellierung die durchschnittliche Anzahl der Schreibvorgänge über alle NAND auf der Festplatte. Dies bedeutet, dass im NAND Ihres Laufwerks durchschnittlich 245 volle Schreibzyklen stattfanden. Siehe Samsung SSD "Wear_Leveling_Count" Bedeutung .
    • Dies basiert auf der NAND-Rohkapazität einschließlich des verfügbaren Speicherplatzes.
    • Lesevorgänge werden für diese Anzahl nicht berücksichtigt (es sei denn, die SSD muss die Daten aufgrund von Lesestörungen neu schreiben ).
  • Der genaue Bereich für normalisierte Werte variiert je nach Antriebshersteller. Bei den meisten Antrieben liegt der Verschleißniveausatz im Bereich von 0 bis 100. Es wird geschätzt, dass auf Ihrem Laufwerk noch etwa 93% der Schreibdauer verbleiben. Die meisten anderen normalisierten Werte dieses Laufwerks liegen ebenfalls im Bereich von 0 bis 100. (Das NAND des 840 PRO ist für etwa 3500 Schreibzyklen geeignet, und 245 Zyklen sind 7% dieser Zahl.)
  • Die normalisierten Attributwerte 254 und 255 werden als reserviert betrachtet und sollten auf keinem Laufwerk angezeigt werden.
Was ist die Motivation, die Daten zu Github Gist neu zu buchen? Redundanz? Ich habe vermutet, dass es 245 mal von den SMART-Daten auf dem Screenshot überschrieben wurde. Ich habe keine Ahnung, ob das stimmt. Kann man dem Kernel mitteilen, dass er Trim aktivieren soll, nicht aber asynchrones Trimmen? UTF-8 vor 7 Jahren 0
Gist wird im Allgemeinen als ein besserer Ort für die Veröffentlichung von Textmustern betrachtet als Pastebin. Ja, Ihre Interpretation der SMART-Daten ist korrekt. Ich scheine jedoch keine Informationen zu finden, die nur das synchrone Trimmen ermöglichen. bwDraco vor 7 Jahren 0
Ich denke, neuere Linux-Kernel ermöglichen nur das synchrone Trimmen (asynchrones oder in der Warteschlange befindliches Trimmen ist deaktiviert) auf diesen SSDs, aber nicht absolut sicher. Was ist deine Kernelversion? bwDraco vor 7 Jahren 0
Ich habe [diese andere Frage] (http://unix.stackexchange.com/questions/333635/enabling-synchronous-trim-only) erst erstellt, nachdem Sie geschrieben haben: "Ich kann anscheinend keine Informationen finden, die nur das synchrone Trimmen ermöglichen. " Da ich auch schon vorher ziemlich viel gegoogelt habe, sollte die Lösung des Problems wahrscheinlich getrennt vom Verständnis der SMART-Werte diskutiert werden. Mein Laptop verwendet Linux `4.4.0-57-generic`. UTF-8 vor 7 Jahren 0
Ich habe bemerkt, dass Timming die ganze Zeit eingeschaltet war, weil Ubuntu einen Cron-Job hat, der `/ sbin / fstrim --all || ausführt einmal in der Woche. Ich habe den Cron-Job so gewechselt, dass er einmal täglich ausgeführt wird und etwas Speicherplatz auf meiner SSD verfügbar ist, sodass ich immer 25 bis 35 GB freien Speicherplatz habe. Die Anzahl der geschriebenen LBAs hat sich seitdem jedoch nur auf 47'336'457'217 erhöht, was bedeutet, dass ich 557 GB schrieb, während der Verschleißwert auf 253 gestiegen ist, was bedeutet, dass inzwischen 2'048 GB geschrieben wurden die SSD. Schreibverstärkung ist jetzt 4 mal, nicht 3. Kann ich etwas dagegen tun? UTF-8 vor 7 Jahren 0
Vor 4 Tagen habe ich den Cron-Job so geändert, dass er die Zeit bis zum Ausführen des Trimmbefehls und die Zeit danach in eine Textdatei schreibt. Es dauert (ziemlich konstant) 35 Sekunden, um den Befehl jedes Mal auszuführen: https://paste.ubuntu.com/24042979/ Ich habe auch getestet, wie lange der Befehl zum Trimmen benötigt, wenn er zweimal hintereinander ausgeführt wird. Der zweite Anruf wird sofort zurückgegeben. UTF-8 vor 7 Jahren 0
@ UTF-8: Die Schreibverstärkung ist bei zufälligen E / A normalerweise am schlechtesten. 25-35 GB sind auch nicht viel freier Speicherplatz. Dieser Speicherplatz kann während des normalen Betriebs der SSD (vom Standpunkt des SSD-Controllers) leicht erschöpft werden. Wenn Sie nicht mehr Speicherplatz freigeben können, sollten Sie häufiger TRIMs ausführen, um sicherzustellen, dass der Controller über freien Speicherplatz verfügt. es täglich zu ändern, ist ein guter erster Schritt. Möglicherweise möchten Sie auch 'fstrim' manuell nach schreibintensiven Aufgaben ausführen. bwDraco vor 7 Jahren 0
Die konstanten 35 Sekunden pro TRIM sind ein Zeichen dafür, dass ständig freier Speicherplatz auf dem Laufwerk zur Verfügung steht. Es ist möglicherweise am besten, TRIM stündlich auszuführen. bwDraco vor 7 Jahren 0
Ich habe es jetzt in stündlich geändert und den Schreibcache für die SSD in `gnome-disks 'aktiviert. Ungefähr 60 bestanden, seit ich meine Frage geschrieben habe, und ich habe in dieser Zeit anscheinend rund 600 GB geschrieben. Das bedeutet etwa 10 GB pro Tag, mehr als ich durchschnittlich pro Tag geschrieben habe, aber nur ein Drittel des Speicherplatzes, den ich frei halte. Was meinen Sie mit "aus Sicht des SSD-Controllers"? Dass nur ein ganzzahliger Wert von Blöcken gleichzeitig geschrieben werden kann und der LBA-Schreibzähler sich nicht darum kümmert? (Es endet in '17', was ein schlechtes Zeichen ist.) UTF-8 vor 7 Jahren 0
Was der Controller als frei ansieht, ist nicht dasselbe, was das Betriebssystem als frei ansieht. Vielleicht wäre es am besten, es im Chat zu besprechen. http://chat.stackexchange.com/rooms/118/root-access bwDraco vor 7 Jahren 0
Zum Nutzen der Leser habe ich die Chat-Diskussion mit einem Lesezeichen versehen (hier: http://chat.stackexchange.com/rooms/118/conversation/understanding-how-free-space-and-trim-impact-write-amplification) ). bwDraco vor 7 Jahren 0

Verwandte Probleme