Einmal ein SATA Secure Erase Kommando drüber und schon sollte das Problem, so es eines ist, gelöst sein.
Interessant wird das, wenn das Filesystem nicht direkt auf der SSD sitzt sondern da noch einige Layer zwischen sind. Volumemanager, Cryptolayer...
Gerrit
Gerrit Heitsch schrieb:
Ein Stromausfall ist nicht das Problem. Ein Problem bekommst du dann, Wenn eine SSD jahrelang unbenutzt herumliegt, ohne einmal Strom zu sehen. Dann gehen deine Daten u.U. in den Orkus. BTDT.
Guido
Ja, kenne ich. Wenn dann auch noch die Firmware der SSD auf dem Flash ist und im echten 'ROM' nur ein Bootloader hast du eine SSD gehabt.
Ich hab eine SSD in einem externen 2.5" Gehäuse, die brauche ich selten. Zur Sicherheit hänge ich die alle paar Monate für einen Tag an den Rechner damit sie Strom hat und der Controller seinen Job machen kann.
Gerrit
Am 15.11.22 um 17:23 schrieb Bernd Laengerich:
Secure Erase könnte helfen. Ist aber unklar, wie der jeweilige Hersteller das implementiert.
Na ja, wenige Prozent. Früher war TRIM ein Problem, wenn man Linux mit Systemverschlüsselung einsetzte, aber inzwischen geht das wohl auch.
Hanno
Wahrscheinlich wissen das hier ohnehin alle, trotzdem:
Ich habe vor einiger Zeit drei Marken-USB-Stricks (Sandisk) gekauft und zum Verteilen in der Familie zu drei Vierteln gefüllt. Wegen Covid fiel das Familientreffen aus. Ein Jahr später habe ich sie testgelesen mit einem Vergleich auf Dateiinhalte. Der Test ging bei allen drei sehr schnell. Die Fehlerrate war überall derart hoch, daß ich rasch abbrechen konnte. Ich habe sie also alle drei neu beschrieben und die Empfänger darauf hingewisen, sie bald auszulesen und nicht nur in die Schublade zu legen.
Manchmal passiert das ja auch ganz automatisch. Zumindest habe ich gelegentlich den Eindruck, daß irgendwelche Windows- oder Linuxpartitionen nicht die volle Kapazität der SSD nutzen, sondern wegen irgendwelcher Partitionsgrenzen noch ein Bisserl was übrigbleibt.
Genau.
Außerdem erinnere ich an den Thread "Der leise Tod einer SSD...?" ab Message-ID: <1trl7ryanh12c$. snipped-for-privacy@news.bartheld.net>. Da haben bei einer Samsung 840 Evo mit 120GB (75% Restlebensdauer) weder irgendwelche Formatierungs- oder Neuinstallationsversuche funktioniert, um die schwächelnde Leistung wieder herzustellen. Ultima Ratio:
Volker
Message-ID: <1swoaw81084c0$. snipped-for-privacy@news.bartheld.net>
Das Problem könnte natürlich auch ein anderes gewesen sein. Das Sympton "SSD wird lahm" des nämlichen Exemplars besserte sich durch ein SATA Secure Erase jedenfalls nicht.
Volker
Sichwort Alignment. Sollte aber nicht viel ausmachen.
Es gibt noch einen weiteren Grund, die Platten nicht ganz auszureizen: Nicht alle Hersteller interpretieren 2TB (oder sonstwas) auf das GB genau gleich. Versucht man dann, eine ausgefallene Platte durch eine "gleich große" andere zu ersetzen, kann es sein, daß das nicht paßt.
Ich hab gerade ein RAID1 aus zwei nominell gleich großen, aber absichtlich nicht baugleichen SSDs gebaut, da war der Unterschied 45GB. Ich hab dann bei der kleineren bei der Partitionierung noch mal so viel freigelassen, einerseits für Overprovisioning als TRIM Ersatz, andererseits als Reserve, falls eine Ersatzplatte noch kleiner sein sollte.
Hanno
Am 15.11.22 um 17:23 schrieb Bernd Laengerich:
Schwund ist immer dabei. Alle SSDs haben als Reserve oder für Verlagerung physisch mehr Speicher als logisch.
Der Grad der Überprovisionierung kann von 7% bei Consumer bis 50 Prozent für spezielle Serverplatten betragen.
Einige Hersteller bieten Werkzeuge an mit denen sich die Überprovisionierung nachträglich anpassen lässt.
O.J.
Wie soll das gehen? Jeder Sektor, den Du schreibst, gibt einen Sektor im alten Block frei, der nicht umkopiert werden muss. Wo sollen da auf einmal in Summe mehr Daten herkommen?
cu Michael
Ich habe hier das Gegenteil - das war eine SSD, die durch Betrieb in einem dauerlaufenden Router mit reichlich logging schnarchlangsam geworden war. Überschreiben mit Nullen hilft nicht. Nach einem secure erase ist die wieder flott.
Das war eine 32GB von Apacer, also nicht unbedingt high-end.
cu Michael
Hallo Volker,
Du schriebst am Tue, 15 Nov 2022 22:05:43 +0100:
Ja, nachdem ja Speicherplatz inzwischen sowieso nix mewhr kostet, ist das auch kein Problem mehr. Früher hätte das bedeutet, daß der benutzte Platz dadurch das 5-fache (ge)kostet (hätte).
BTW, wo gibt's eigentlich diese kostenlosen SSDs u.ä.? Ich finde immer nur welche mit Preisen...
Irgendwann ist auch eine SSD mal voll, ebenso wie eine konventionelle Festplatte irgendwann voll ist. Nach dem Beschreiben des letzten freien Blocks ist eben Schluß. Aber das ist natürlich keine Besonderheit einer SSD...
MfG Rupert
Nein. Eine SSD hat immer Reserveblöcke, ich hatte für die Erklärung genau einen mehr als die nutzbare Kapazität angegeben - dann geht das immer auf.
Wegen Wearleveling hast Du mehr als einen, und die garbage collection optimiert das natürlich so, daß möglichst hohe Performance dabei rauskommt, aber das Szenario "durch Überschreiben sind keine leeren/löschbaren Blöcke mehr da" kann bei korrekter Verwaltung nicht auftreten.
Firmwarebugs sind ein getrenntes Thema ...
cu Michael
Hanno Foest schrieb:
Der Unterschied zwischen Block (Win: Cluster) und Sektor. Solange der alte Block noch Daten enthält, ist er nicht frei. Im schlimmten Fall ist noch 1 Sektor pro Block belegt und alle übrigen wurden auch schon einmal geschrieben, dann ist kein Block mehr frei (zum Löschen).
DoDi
Hallo Michael,
Du schriebst am 16 Nov 2022 19:36:12 GMT:
"Möglicherweise" hat die das Überschreiben mit Nullen als "Vollschreiben" interpretiert, weil sie als Zustand "gelöscht" evtl., wie bei "vielen" elektronischen Festwertspeichern, den ansieht, in dem alle Bits gesetzt ("1", "high") sind. Dazu hättest Du sie evtl. mit lauter "0xFF" beschreiben müssen. Das ginge allerdings auch nur, wenn sie nicht die Schreiboperationen in einem internen Bereich als solche registriert, der nur mit diesem "secure erase" zurückgesetzt werden kann. Es sagt einem halt kein( Herstell)er, was da in einzelnen abläuft.
Dann hat die Firmware vorher schon was falsch gemacht. Wenn nur noch 1 Block frei ist, muss man halt umkopieren, und dadurch wird der alte Block wieder frei. Einfach nur den neuen (letzten) Block mit Daten belegen geht nicht.
SSD-Blöcke sind nochmal was anderes als Cluster - das ist aber egal, die Firmware muss dafür sorgen, daß immer mindestens einer frei ist, damit sie alte Daten umkopieren kann.
cu Michael
Oder sie sieht sich die Daten überhaupt nicht an und schreibt die immer 1:1, und man braucht halt trim oder secure erase, um Blöcke wirklich wieder freizugeben. Zu den Interna der SSD-Firmwaren gibt es kaum detaillierte Angaben.
Das ist aus meiner Sicht auch OK: trim und secure erase existieren und funktionieren, das Überschreiben war nur ein Test um zu sehen, wie sich das Teil verhält.
cu Michael
Am 18.11.2022 um 18:35 schrieb Michael Schwingen:
Sich die geschriebenen Daten nicht anzusehen wäre in erster Näherung ja auch sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er recyclet hat. Und die beschreibbare Größe könnte die tatsächliche Größe übersteigen, je nach Inhalt. Und der Controller könnte dann out of memory laufen wenn jemand in die "leeren" Blöcke mal ein 1-Bit schreibt.
Bernd
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.