Kann ich TRIM simulieren, indem ich alle Nullen schreibe?

1042
ivan_pozdeev

Bevor auf einen SSD-Sektor 1 geschrieben wurde, sieht es aus, als wären alle mit Nullen gefüllt.

Wenn ich also aus Gründen der Funktionalität alle Nullen in einen Sektor schreibe, sieht es wie ein freier aus. Die Steuerung hat somit eine technische Möglichkeit, sie als solche zu behandeln. Mein begrenztes Wissen über die IC-Architektur besagt, dass das Herunterfahren einer Schaltung für alle Nullen in Bezug auf die Hardware wahrscheinlich vernachlässigbar wäre, wenn überhaupt.

Die Frage ist: implementiert irgendein Flash / SSD-Controller dieses oder ähnliches tatsächlich?

Dies gilt sogar für Flash-Speicher, der über Schnittstellen angeschlossen wird, die nicht über den TRIM-Befehl verfügen, wie z. B. USB.

In den Antworten, die bis jetzt gepostet wurden, skizzierten einige Leute mögliche Show-Stopper-Probleme. Dennoch erwiesen sich alle als Nicht-Themen. Wenn es nicht Beweise gibt, dass dies wirklich ernsthafte Probleme sind, behaupten Sie bitte nicht autoritär, dass sie es sind, sondern sagen Sie ehrlich, dass Sie nur eine Hypothese aufstellen.


1 Ein logischer Sektor, dh was der Host sieht.

1
SSDs nutzen sich schnell ab, wenn Sie in jeden Sektor schreiben. Jede Zelle hat eine begrenzte Anzahl von Malen, in die geschrieben werden kann, und danach ist die Zelle zu langsam, um nützlich zu sein. Wenn Sie aus Sicherheitsgründen ein "sicheres Löschen" des Laufwerks haben, sollten Sie wissen, dass die meisten SSDs übermäßig verfügbar sind, sodass physische Zellen übrig bleiben. Daher kann jemand, der ein Anbieter-Dienstprogramm für den Zugriff auf jede einzelne Zelle verwenden kann, Zugriff auf Daten haben, die Ihrer Meinung nach "sicher gelöscht" wurden. Christopher Hostage vor 6 Jahren 0
Klingt so, als ob Sie fragen, ob ein Controller die Garbage Collection durchführen würde, indem Sie prüfen, ob ein * logischer * Block (um weniger eindeutig zu sein, * liest *) alle Null enthält? (Wie Auto-TRIM, wenn das der Fall ist?) Tom Yan vor 6 Jahren 0
@ TomYan Es ist noch einfacher. Es muss nur bei einem eingehenden Schreibbefehl geprüft werden. Wenn der Datenoperand nur aus Nullen besteht, wird nicht geschrieben, und der logische Block wird nicht zugeordnet. ivan_pozdeev vor 6 Jahren 0
Ich habe von Controllern gehört, die * intelligent * genug wären, um die Nullfüllung zu ignorieren, nachdem eine bestimmte zusammenhängende Länge überschritten wurde. Ich würde davon ausgehen, dass (ein Teil der) logischen Blöcke in einem Zustand sind, der mit TRIM gleichwertig ist. Tom Yan vor 6 Jahren 1
@TomYan Ich habe gelesen, dass SSDs (wie Samsung PRO / EVO) Top-Gun-Daten im laufenden Betrieb komprimieren, um noch schnellere Lese- / Schreibgeschwindigkeiten zu erreichen - natürlich komprimiert ein Teil von Nullen wirklich gut. ivan_pozdeev vor 6 Jahren 0
"Wenn also keine Beweise vorliegen, dass es sich wirklich um ernsthafte Probleme handelt, sind die Antworten, die autoritativ behaupten (und nicht nur eine Hypothese aufstellen), nicht akzeptabel." - Sie sind aus Gemeinschaftssicht akzeptabel. Sie könnten Ihre Frage einfach nicht beantworten. Ich warne Sie davor, Worte wie "nicht akzeptabel" zu verwenden. Als Autor der Frage möchten Sie, dass so viele Leute bereit sind, eine Antwort zu schreiben, negative Worte können Menschen jagen, die die Antwort auf Ihre Frage kennen. Ramhound vor 6 Jahren 0
Ich bin VTC als zu breit, weil es zu viele Flash-Controller-Typen gibt. Sie müssen den Umfang dieser Frage ernsthaft einschränken. Super User ist in keinem Fall ein Recherchedienst. Daniel B vor 6 Jahren 0
@DanielB Es gibt nicht so viele verschiedene Techniken, die von SSDs verwendet werden, und sie werden normalerweise in technischen Veröffentlichungen / Reviews / etc erwähnt. dh Sie benötigen keine Firmware-Kenntnisse über bestimmte Modelle. Controller unterscheiden sich nur in Details ihrer Implementierung, die hier keine Rolle spielen. ivan_pozdeev vor 6 Jahren 0

3 Antworten auf die Frage

1
sawdust

Kann ich TRIM simulieren, indem ich alle Nullen schreibe?

Nein.
Der Schreibvorgang erfordert einen gelöschten Sektor, und dann erfolgt der eigentliche Schreibvorgang.
Der Schreibvorgang ist ein Hinweis für die SSD, dass dieser Sektor verwendet wird (die entgegengesetzte Bedingung, die Sie mit einem echten TRIM-Befehl wünschen).

Bevor auf einen SSD-Sektor geschrieben wurde, sieht es aus, als wären alle mit Nullen gefüllt.

Falsch, und anscheinend beruht Ihre Frage auf dieser fehlerhaften Prämisse.
Ein gelöschter Sektor wird mit Bytes von 0xFF (alle Einsen) gefüllt.

Ein Format schreibt normalerweise alle Nullen in jeden Sektor.

Wenn ich also aus Gründen der Funktionalität alle Nullen in einen Sektor schreibe, sieht es wie ein freier aus.

Nein es wird nicht.
Beachten Sie, dass es auf Dateisystemebene "freie" Sektoren und auf SSD-Ebene "freie" Sektoren gibt. Theoretisch sollte es sich um dieselbe Gruppe handeln. Da jedoch die SSD vom Dateisystem explizit darauf hingewiesen werden muss, dass ein Sektor "frei" ist (mit einem TRIM-Befehl), gibt es Diskrepanzen.

NACHTRAG

Die Steuerung hat somit eine technische Möglichkeit, sie als solche zu behandeln. Mein begrenztes Wissen über die IC-Architektur besagt, dass das Herunterfahren einer Schaltung für alle Nullen in Bezug auf die Hardware wahrscheinlich vernachlässigbar wäre, wenn überhaupt.

Die Frage ist: implementiert irgendein Flash / SSD-Controller dieses oder ähnliches tatsächlich?

Nein, weil dies zu unbeabsichtigtem Datenverlust führen würde.
Immer, wenn ein Programm einen Sektor aller Nullen schreibt (z. B. ein Speicherabbild kann solche Blöcke enthalten), würde Ihr SSD die Möglichkeit haben, diesen Sektor zu löschen, da er ihn als nicht zugeordneten Sektor behandeln würde, anstatt einen Sektor zu verwenden, der gerade verwendet wird eine Datei.

Unterm Strich funktioniert Ihr vorgeschlagenes Schema (mit Dateninhalt) nicht.
Wenn Sie einen Sektor als frei oder nicht verwendet kennzeichnen möchten, gibt es den Befehl TRIM.
Es gibt keine Ersatzschreiboperation.

`Ein gelöschter Sektor ist mit Bytes von 0xFF (alle) gefüllt .`? Woher kommt dann "RZAT" in ATA und "LBPRZ" in SCSI? (wo das Z Null ist) Tom Yan vor 6 Jahren 0
@TomYan Die Nullen, die diese Befehle zurückgeben, sind nicht das Ergebnis des Lesens des Mediums. Sie werden von der Logik auf dem Laufwerk generiert, wenn Sie "TRIM" d-Blöcke lesen. Jamie Hanrahan vor 6 Jahren 0
@TomYan - Die Dokumentation für Flash-Chips gibt eindeutig an, dass der gelöschte Zustand alle Einsen ist. Die Dokumentation für SSD zeigt eindeutig an, dass der Controller * mit * Nullen für die Daten antwortet, wenn dieses Flag für einen "freien" (dh nicht zugeordneten) LBA / Sektor gesetzt ist. Dies bedeutet nicht, dass der LBA / Sektor tatsächlich Nullen enthält, da dies die Leistung tatsächlich beeinträchtigen würde (dh es wird nicht gelöscht und kann nicht geschrieben werden). Siehe den letzten Absatz von Abschnitt 3.8.2 von http://www.seagate.com/www-content/product-content/ssd-fam/1200-ssd/en-us/docs/100708406b.pdf sawdust vor 6 Jahren 2
@sawdust siehe meinen Kommentar in der Antwort von David Schwartz. Tom Yan vor 6 Jahren 0
_> und anscheinend basiert Ihre Frage auf dieser fehlerhaften Prämisse._ Sie können kein Vater der Wahrheit sein. Meine Frage hängt nicht im geringsten davon ab, welches Muster genau geschrieben werden muss. Mit "scheint mit Nullen gefüllt zu sein" meine ich, dass Nullen an den Host zurückgegeben werden. Ich bin mir ziemlich sicher, dass in diesem Fall überhaupt kein (Nicht-Metadaten-) NAND-Lesen durchgeführt wird. ivan_pozdeev vor 6 Jahren 0
@sawdust Auch wenn es den logischen Block gibt, wenn er Null liest, "enthält" er Null. Deshalb wurde es "logischer" Block genannt. Tom Yan vor 6 Jahren 0
@sawdust Zum Schluss habe ich vorgeschlagen, dass solche "Schreibvorgänge" auf besondere Weise gehandhabt werden können, ohne tatsächlich Blöcke (Nicht-Metadaten) zu löschen oder zu überschreiben. Es sieht fast so aus, als hätten Sie meinen Beitrag überhaupt nicht gelesen, bevor Sie geantwortet haben. ivan_pozdeev vor 6 Jahren 0
_Wenn immer ein Programm einen Sektor aller Nullen geschrieben hat ... Ihr Schema würde es der SSD ermöglichen, ... sie als einen nicht zugeordneten Sektor zu behandeln, anstatt einen Sektor zu verwenden, der einer Datei zugeordnet ist. _ Schon immer von [spärlichen Dateien] ( https://en.wikipedia.org/wiki/Sparse_file)? Solange der Host aus einem bestimmten logischen Sektor genau das liest, was er zuvor geschrieben hat, ist es egal, wie das Laufwerk intern damit umgeht. Es ist nicht so, als ob ein nicht zugeordneter _logical_-SSD-Sektor plötzlich anfangen könnte, etwas anderes als Nullen zu enthalten, oder? ivan_pozdeev vor 6 Jahren 0
@ivan_pozdeev * "Solange der Host aus einem bestimmten logischen Sektor genau liest, was er zuvor geschrieben hat, ist es egal, wie das Laufwerk intern damit umgeht" * - Nicht wahr. Ich habe an Systemen gearbeitet, die nullgefüllte Dateien geschrieben haben, um sicherzustellen, dass die Sektoren zugänglich und zugewiesen sind, dh um zu gewährleisten, dass das Schreiben (erneuten) Schreiben dieser Datei keinen "Out-of-Space" -Fehler verursacht. Beachten Sie, dass "Sparse" -Dateien nur auf Dateisystemebene implementiert werden sollten (was definieren kann, was "keine Daten" ist) und nicht auf Speichermedienebene. sawdust vor 6 Jahren 1
@sawdust Guter Punkt zu "out of space". Dies gilt jedoch nicht für SSDs, da sie die gesamte angekündigte Datenkapazität auf einmal halten können. Ich habe nie vorgeschlagen, alle Eigenschaften von Dateien mit geringer Dichte wie die Eigenschaft zu verwenden, um größer als der verfügbare Speicher zu sein. Nur die Eigenschaft, dass die Blöcke, die alle Nullen sind, nicht wirklich gespeichert werden müssen. ivan_pozdeev vor 6 Jahren 0
1
David Schwartz

Tatsächlich ist ein gelöschter SSD-Sektor mit Einsen gefüllt, nicht mit Nullen. Sie verwechseln SSD-Sektoren (die eigentlichen physischen Sektoren auf der SSD, die wir trimmen möchten) mit Plattensektoren (die logischen Sektoren, die die SSD dem Dateisystem präsentiert, nachdem sie mit ihrer Verwaltungsmagie fertig sind). Das Füllen von logischen Sektoren mit Null würde die Trimmung aufheben, da dies die SSD dazu zwingen würde, gelöschte physische SSD-Sektoren zuzuordnen und sie mit Nullen aufzufüllen.

Wenn ein logischer Sektor getrimmt wird, nimmt die SSD alle physischen Sektoren auf, die diesem logischen Sektor zugeordnet sind. Wenn es eine Chance hat, löscht es sie und füllt sie mit Einsen. Nach dem Löschen werden sie zu einem Pool gelöschter physischer Sektoren hinzugefügt. Das Zuschneiden zielt darauf ab, den Pool der gelöschten physischen Sektoren zu vergrößern.

Wenn Sie einen logischen Sektor lesen, der keinen entsprechenden physischen Sektor hat, gibt das Laufwerk eine Seite mit Nullen zurück. Es muss jedoch weder einen physischen Sektor lesen, noch kann dies der Fall sein, da keine physischen Sektoren zugeordnet sind.

Sehen Sie hier für weitere Details.

@ RickBrant Mein Punkt ist, ob die physischen Sektoren hinter der Szene "einseitig" sind, liegt außerhalb des Geltungsbereichs des OP (ich denke auch nicht, dass "eins" eine gute Möglichkeit ist, wenn man über das elektronische Niveau spricht). Was das OP wissen muss, ist, dass die logischen Blöcke, die Null gelesen werden, nicht notwendigerweise bedeuten, dass ein physischer Sektor freigegeben wird. Ansonsten würde er natürlich mit der Frage kommen: "Kann ich TRIM durch One-Filling emulieren"? Es ging nie darum, wie ein Sektor gefüllt wird, sondern lediglich um seinen Zustand im Sinne von "Bereitstellung logischer Blöcke". Tom Yan vor 6 Jahren 1
@ TomYan Ich stimme dir nicht zu. Mit einer solchen Frage würde er nicht wiederkommen, weil er weiß, dass das Lesen im getrimmten Sektor alle Nullen zurückgibt. Das Verständnis des Unterschieds zwischen physischen und logischen Sektoren ist für das Verständnis von TRIM unerlässlich, weshalb das Schreiben kein Ersatz dafür ist. David Schwartz vor 6 Jahren 0
@DavidSchwartz Ich weiß, wie TRIM funktioniert. Und genau aus diesem Grund wurde eine technisch mögliche Emulationsmethode abgeleitet: Solche Schreibvorgänge können auf eine spezielle Art und Weise behandelt werden, die genau das tut, was TRIM tun würde. ivan_pozdeev vor 6 Jahren 0
Beschnittene Sektoren geben möglicherweise nicht notwendigerweise Null zurück, nicht auf allen Laufwerken. Deshalb gibt es das "Bit" von RZAT / LBPRZ. Es hängt völlig von der Implementierung des TRIM auf den Laufwerken ab. Sicher ist es eine gute Sache zu wissen, was der "Reset" des elektronischen Zustands eines "physischen SSD-Sektors" ist, aber wenn man ihn einseitig nennt und mit Zuständen auf der logischen Blockschicht vergleicht? Ich sehe nicht, wie angemessen oder richtig es ist. Tom Yan vor 6 Jahren 0
@TomYan - * "Ich denke auch nicht" Eins "ist ein guter Weg, wenn Sie über das elektronische Niveau sprechen" * - Raw-Flash, der gelöscht wurde, wird als Ganzes gelesen. sawdust vor 6 Jahren 0
"Ich weiß, wie TRIM funktioniert." - Warum haben Sie daraus gefolgert, dass Sie bekommen würden, was Sie wollen, wenn Sie das Laufwerk mit 0 statt mit 1 füllen? Ramhound vor 6 Jahren 0
@Ramhound, weil _Bevor noch in einen SSD-Sektor * geschrieben wurde, sieht es aus, als wären alle mit Nullen gefüllt. (* Ein logischer Sektor, dh was der Host sieht.) _ ivan_pozdeev vor 6 Jahren 0
@sawdust Ich habe nie gesagt, dass es nicht so ist. Bei dem Satz, den Sie zitiert haben, ging es nie darum, diese Tatsache zu beanstanden. Es ging darum, es als "Eins (erfüllt)" zu bezeichnen, es ist irreführend, als ob es darum geht, diese in / durch die logischen Sektoren zu schreiben. Deswegen bevorzuge ich "reset" oder was auch immer die "Ladung" ist (positiv / negativ). Noch wichtiger ist, dass die "One-Filled-Tatsache" hier keine Rolle spielt, da es auch "One-Filled" (elektronisch / physischer Sinn) wäre, wenn Sie "One-Filled" (logischer Sinn, alias normales Blockschreiben) dazu haben, aber es bedeutet nicht, dass es "nicht zugeordnet" / "nicht verwendet" / "trim'd" ist. Tom Yan vor 6 Jahren 0
1
LawrenceC

Kann ich TRIM simulieren, indem ich alle Nullen schreibe?

Nein.

So funktioniert Flash:

  • Ungeschriebenes Flash ist nur eine 1, und Schreibvorgänge ziehen die 1 auf 0 zurück.

  • Flash wird in einer Menge von Bytes geschrieben, die als Seite bezeichnet wird. 2048 Bytes sind ein Beispiel für eine Seitengröße. (Es gibt auch eine kleine Datenmenge - etwa 64 Bytes, die auch Teil der Seite sind, auf der ECC-Informationen gespeichert werden können.)

  • Was ist, wenn Sie 0's wieder in 1 ändern wollen. Sie können es nicht, es sei denn, Sie löschen die Seite.

  • Wenn Sie Flash löschen, wodurch alle Bits auf 1 zurückgesetzt werden, wenn die Seite nicht beschädigt ist, ist die Anzahl der zu löschenden Bytes (die aus Linux-Terminologie zu entleihende Löschblockgröße ) normalerweise größer als die Seitengröße. 128k ist ein Beispiel für eine Löschblockgröße.

  • Das Löschen dauert viel mehr als nur das Schreiben einer Seite.

Weil:

  • SSDs geben vor, als wären sie Standard-Festplatten für den Host. Standard-Festplattenlaufwerke arbeiten mit 512-Byte-Sektoren (LBAs genannt und der Kapazität des Laufwerks, die von 512 geteilt wird, mit 0 nummeriert), nicht 2048 oder einer anderen Größe.

  • und die SSD-Firmware muss im Hintergrund viele Fälschungen ausführen, da es wirklich keine 512-Byte-Speicherplätze gibt, um die Daten wie auf einer sich drehenden Festplatte zu speichern.

  • und das Schreiben auf eine Seite, die nicht gelöscht werden muss, ist schneller als das Löschen und dann das Schreiben.

SSDs verwalten eine sogenannte LBA-to-PBA-Tabelle. Das Betriebssystem beispielsweise sagt der SSD, dass sie in die LBA 20 schreiben soll, aber es könnte wirklich etwas wie "Flash-Chip 2 Seite 56" sein. Dies wird in der LBA-to-PBA-Tabelle beibehalten.

Die SSD-Firmware versucht, Schreibvorgänge auf neue Seiten zu leiten und das Löschen zu vermeiden, sofern dies nicht erforderlich ist. Wenn keine ungeschriebenen Seiten zur Verfügung stehen, müssen die Dinge neu gemischt und gelesen / möglicherweise an einem anderen Ort geschrieben / eraseblock / ein Haufen Zeug zurück geschrieben werden.

Die LBA-zu-PBA-Tabelle kann also völlig zufällig sein.

TRIM teilt der SSD mit, dass es Einträge aus dieser Tabelle entfernen kann (oder als "LBA noch nicht beschrieben" kennzeichnen kann) und tatsächlich Flash löschen und für spätere Schreibvorgänge verfügbar machen kann.

Deshalb ist das Schreiben von 0x00 oder 0xFF nicht gleichwertig. Nur TRIM teilt der Firmware mit, es sei in Ordnung, Dinge in dieser Tabelle nicht zu verfolgen, Flash als nicht verwendet zu betrachten und als Vorbereitung für neue Schreibvorgänge zu löschen.

Das Schreiben aller Ergebnisse von 0x00 oder 0xFF in eine vollständige LBA-to-PBA-Tabelle, in der die von Ihnen verwendeten Daten verfolgt werden, und die Dinge werden langsam bleiben, da sie die Dinge umstellen und lesen, löschen und umschreiben müssen.

Noch ein weiteres Problem. Da das beschriebene "spezielle Schreiben" nur die "LBA-to-PBA-Tabelle" betrifft, spielt es keine Rolle, dass Seiten / Löschblöcke größer sind als logische Sektoren - nichts würde tatsächlich in NAND geschrieben. Das einzige Problem ist, dass ein Block als "teilweise frei" markiert werden muss. TRIM akzeptiert jedoch auch einen Satz logischer Blockbereiche (siehe https://stackoverflow.com/questions/3267244/ata-trim-specification/3267568#3267568) für eine Spezifikationsverbindung), so muss der Antrieb mit einer solchen Situation ohnehin zurechtkommen. ivan_pozdeev vor 6 Jahren 0
Ich würde es nicht vor einigen beschissenen Firmwares geben, um die Nullen tatsächlich in den Flash zu schreiben. Sie können nicht wissen, was die Firmware tut, wenn Sie nicht über den Quellcode verfügen, ihn kompilieren und ihn selbst auf dem Gerät installieren - oder der Firmware-Hersteller das spezifische Verhalten ausdrücklich garantiert. Möglicherweise können Sie jedoch das wahre Verhalten durch Messen des Timings von Befehlen erkennen. LawrenceC vor 5 Jahren 0