TRIM bei Schnellformatierung?

H

highks

Gast
Wenn ich eine SSD in einem USB Gehäuse stecken habe, dann wird sie dort ja normalerweise nicht getrimmt.

Jetzt frage ich mich, ob vielleicht eine Schnellformatierung der SSD (immer noch im USB Gehäuse) dazu führt, dass alle Zellen getrimmt werden, oder ist das nicht der Fall?

Wenn das nicht der Fall ist, muss man dann einfach damit leben, dass sich eine SSD im externen USB Gehäuse einfach überhaupt nicht trimmen lässt?
Ein Secure Erase ist im USB Gehäuse so weit ich weiß ja auch nicht möglich.
 
Der Kollege ist auch hier vertreten und ich habe das ganze hier schon mal vor einiger Zeit zusammen gefasst. Wie gut eine SSD ohne TRIM klar kommt, hängt immer von der jeweiligen SSD ab. xbitlabs macht in seinen SSD Reviews auch immer einen entsprechenden Test wie diesen hier:



Wie man sieht, reicht der vorletzte Balken nie an den letzten (mit TRIM) heran und bei den Sandforce reicht auch der letzte nicht an den ersten (Neuzustand) heran.
 
... aber mal unabhängig davon, wie dringend oder nicht dringend TRIM nötig ist: wird eine SSD im USB Gehäuse, wenn man sie normal formatiert (Schnellformatierung) so gelöscht, dass die Zellen wieder leer sind?
Von mir aus kann das auch die Garbage Collection ohne TRIM machen, das wäre ja egal.
Oder bleiben die Zellen dann für immer gefüllt und müssen beim nächsten Schreiben zuerst gelöscht werden?
 
Wenn Du eine Schnellformatierung machst, sollte es eigentlich mehr oder weniger egal sein, es werden ja nur die wirklich nötigen Datenstrukturen angelegt, alles was dabei geschrieben wird, muss also sowieso bleiben. Windows macht wohl dann auch ein TRIM über alle anderen LBAs, aber 100%ig kann ich das auch nicht sagen.

Hallo32, lies Dir doch bitte mal die von in #3 von mir verlinkte Erklärung über TRIM und GC, dann verstehst Du wieso das jetzt total falsch war und der Controller der SSD damit nichts zu tun hat.
 
@Holt
Wie die GC funktioniert ist mir bekannt. Sobald die Daten eines LBA durch neue ersetzt werden, wird die alte Page für die GC markiert.

Beim Quick Format findet nur eine Zuweisung für die LBAs statt, die die notwendige Informationen für das Dateisystem beinhaltet und dieses sind nur einige wenige Prozent des Speicherplatz. -> Entsprechender Effekt ist also zu vernachlässigen.

Spannend würde es dann werden, wenn eines der Entwicklungsteams der Controller Firmware eine Funktion implementiert hat, die das Quick Format erkennt und die entsprechenden Pages für die GC markiert. Ob diese Funktion existiert ist nur durch Testen und Anfragen herauszubekommen.
 
Samsung hatte mal eine Erkennung des Filesystems um die gelöschten zu finden, das war noch vor der Einführung von TRIM und wenn man diese SSDs in einem RAID 0 einsetzt, gibt es Datensalat, weil die Verwaltungsdaten des Filesystems sich eben auf Cluster des RAID beziehen, aber eben offenbar als lokale Cluster interpretiert wurden. Das hatte nur eine FW Version und es wurde zurecht wieder aufgegeben, weshalb ich nicht erwarten würde, dass so etwas in der Art noch einmal irgendwo implementiert wurde. Die Informationen welche LBAs nicht mehr gültige Daten enthalten, kann und darf nur vom Betriebssystem über die TRIM Befehle kommen bzw. durch das Überschrieben eines LBAs!
 
Falls ein Befehl, welcher sich auf die abstraktes Adressierung eines Raid Volumens 1 zu 1 an den Datenträger des Raids durchgereicht wird, dann ist je nach Verwendung das Software Raid bzw. der HBA verbugt.

Einen Zusammenhang mit einer SSD sehe ich nicht.
 
Nein, das war ja damals in der FW der SSD, die hat das Filesystem ausgewertet und wenn das "Gelöscht" Flag in den Verwaltungsdaten einer datei gesetzt wurden, dann die zugehörigen LBAs der Datei ermittelt und diese gelöscht. Das klappte bei einer einzelnen SSD auch prima, aber bei 2 der SSDs im RAID eben nicht, weil die Verwaltungsdaten des Filsystems halt Cluster adressieren, die sich auf das RAID beziehen, nur hat die FW das eben nicht erkannt und diese Cluster falsch auf lokale LBAs umgerechnet und damit Datenverluste produziert. Man kann eben in einer FW nie alle Eventualitäten abdecken und daher muss die Entscheidung, welche LBAs nun abgeräumt werden können immer von der Instanz kommen, die das verwaltet und das ist das Betriebssystem. Dafür wurde ja extra der TRIM Befehl eingeführt, das hat man ja nicht aus Spaß gemacht, sondern weil es einfach keine wirklich sinnvolle und sichere Alternative dazu gibt.
 
Bei Raid 1 befindet sich ein vollständiges Filesystem auf den einzelnen Datenträgern, dort passen dann auch die Angaben der LBA.

Bei allen anderen Raid Modi befindet sich kein vollständiges Filesystem auf den einzelnen Datenträgern und somit kann eine fehlerhafte Interpretation eines nicht existierenden Filesystem nicht geschehenen.
 
Zuletzt bearbeitet: (Typo korrigiert)
Nein, ganz sicher nicht! Das RAID 0 macht im Grund etwas ganz Einfaches: Es stückelt den globalen Adressraum des RAID in Stücke auf, die dem Strippsize entsprechen und die gegen dann abwechselnd auf die jeweiligen Members des RAIDs. Das Filesystem weiß nichts von dem RAID, es legt seine Metadaten in den globalen Adressraum des RAID, bei NFTS z.B. der MFT und da diese i.d.R. viel größer als der Strippsize sind, werden die eben auch munter über die Member verteilt. Das Filesystem ist also auch unbrauchbar, wenn nur eine Platte im RAID 0 ausfällt. Nur die Kennung des Filesystems steht an einer Stelle, weil die klein ist und eben immer am Anfang steht, 0x07 in der MBR Partitionstabelle bzw. EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 bei GPT.
 
Bei RAID 1 ist es so, aber man sollte beachten, dass die Platten eines RAID1 auch meist nicht einfach so als einzelne LW verwendet werden können, da die RAID Controller (SW) vorne meist noch Verwaltungsdaten ablegt um die Platte als Teil des RAID zu erkennen. Ein RAID 1 ist also nicht einfach nur eine Spiegelung auf zwei Platten die dann wie Klone einer einzelnen HDDs sind, da gibt es meist Abweichungen in der Datenstruktur.
 
Zurück
Oben