Was ist der geloeschte Zustand bei USB Sticks und SD Karten ?

[Carla Schneider]

Fuer eine Anwendung ohne Dateisystem bei der einfach raw Sektoren beschrieben werden
waere es interessant zu wissen ob man zum loeschen Bytes mit Wert 0 oder 255 draufschreiben muss,
damit danach beim naechsten Beschreiben das nicht nochmal geloescht wird und das damit Zeit kostet und
das Ding unnoetig verschlissen wird.

[Marcel Mueller]

Post by Carla Schneider
Fuer eine Anwendung ohne Dateisystem bei der einfach raw Sektoren beschrieben werden
waere es interessant zu wissen ob man zum loeschen Bytes mit Wert 0 oder 255 draufschreiben muss,
damit danach beim naechsten Beschreiben das nicht nochmal geloescht wird und das damit Zeit kostet und
das Ding unnoetig verschlissen wird.

Weder noch. Da zusätzlich noch ECC Prüfsummen abgelegt werden, obliegt
es letztlich der Stick-Firmware, was sie wirklich schreibt. Und AFAIK
gibt es bei Sticks weder Secure-Erase noch Trim, was eigentlich für
diesen Zweck angesagt wäre.

Wenn man allerdings schon überschreibt, dann sollte man eher die 0
nehmen. Die Chancen, dass die Firmware da anbeißt, sind deutlich besser
als bei 0xff.

Bei allem überschreiben sollte allerdings auch klar sein, dass man nur
die logischen Blöcke überschreiben kann, nicht die (zahlreicheren)
physikalischen. Jemand der Böses will, dürfte nahezu sicher noch
Fragmente der Daten in den Chips finden.


Marcel

[Sebastian Barthel]

Post by Marcel Mueller

Post by Carla Schneider
Fuer eine Anwendung ohne Dateisystem bei der einfach raw Sektoren
beschrieben werden waere es interessant zu wissen ob man zum loeschen
Bytes mit Wert 0 oder 255 draufschreiben muss, damit danach beim
naechsten Beschreiben das nicht nochmal geloescht wird und das damit
Zeit kostet und das Ding unnoetig verschlissen wird.

Ist das nicht eher so, daß bei SSDs und Flashs usf generell schreiben-und-
löschen eins sind ? Soll heißen, der Speicher markiert beim Löschen
einfach die entsprechenden Segmente und merkt sie vor, gelöscht und neu
beschrieben werden sie dann beim nächsten Schreibvorgang.(?)

In dem Fall wäre das dann sogar extrem kontraproduktiv da noch einen
"Löschzylus" durch Überschreiben einzufügen - das verdoppelt dann die
Zahl der Schreibzugriffe über alles, was das Gegenteil von dem ist, was
Du erreichen willst.

Post by Marcel Mueller
Weder noch. Da zusätzlich noch ECC Prüfsummen abgelegt werden, obliegt
es letztlich der Stick-Firmware, was sie wirklich schreibt. Und AFAIK
gibt es bei Sticks weder Secure-Erase noch Trim, was eigentlich für
diesen Zweck angesagt wäre.
Wenn man allerdings schon überschreibt, dann sollte man eher die 0
nehmen. Die Chancen, dass die Firmware da anbeißt, sind deutlich besser
als bei 0xff.

Wenn es um sicheres Löschen geht, könnte ich mir vorstellen, daß es evtl.
gar nicht sinnvoll ist, Blöcke mit gleichem Inhalt zu schreiben. Egal ob
nun 0x00 oder 0xff. Evtl. wird das einfach nur als eine einzige Zahl
zusammen mit der gewünschten Anzahl gespeichert und löscht dann irgendwas
in der Größenordnung von 3 Bytes auf dem Stick.

Post by Marcel Mueller
Bei allem überschreiben sollte allerdings auch klar sein, dass man nur
die logischen Blöcke überschreiben kann, nicht die (zahlreicheren)
physikalischen. Jemand der Böses will, dürfte nahezu sicher noch
Fragmente der Daten in den Chips finden.

Dagegen hilft dann wohl nur sicheres "Zerstören" in Form von Raspel oder
Feuer oder so ...


Gruß, SBn

[Marcel Mueller]

Post by Sebastian Barthel

Post by Marcel Mueller

Post by Carla Schneider
Fuer eine Anwendung ohne Dateisystem bei der einfach raw Sektoren
beschrieben werden waere es interessant zu wissen ob man zum loeschen
Bytes mit Wert 0 oder 255 draufschreiben muss, damit danach beim
naechsten Beschreiben das nicht nochmal geloescht wird und das damit
Zeit kostet und das Ding unnoetig verschlissen wird.

Ist das nicht eher so, daß bei SSDs und Flashs usf generell schreiben-und-
löschen eins sind ? Soll heißen, der Speicher markiert beim Löschen
einfach die entsprechenden Segmente und merkt sie vor, gelöscht und neu
beschrieben werden sie dann beim nächsten Schreibvorgang.(?)

Das ist am Ende Definitionssache, was die Firmware als 0 und als 1
interpretiert. Faktisch kommen ja auch noch Fehlerkorrektur- und
Verwaltungsinformationen dazu. Da wird also nie genau das geschrieben,
was man sendet.

Post by Sebastian Barthel
In dem Fall wäre das dann sogar extrem kontraproduktiv da noch einen
"Löschzylus" durch Überschreiben einzufügen - das verdoppelt dann die
Zahl der Schreibzugriffe über alles, was das Gegenteil von dem ist, was
Du erreichen willst.

Das ist es auf jeden Fall. Der Befehl zum optionalen Löschen heißt TRIM
und der Befehl zum sicheren vernichten der Daten heißt Secure Erase.
Beides führt nicht zu zusätzlichen Schreibzyklen auf die Nutzdaten.
(Es gibt allerdings SSDs, die auf viele kleine Trim-Befehle allergisch
reagieren, weil jeder davon Verwaltungsinformationen schreiben muss, und
die kleinste schreibbare Datenmenge auch da ein Block ist.)

Dummerweise kann die USB MSD Spezifikation nichts von alle dem.

Post by Sebastian Barthel
Wenn es um sicheres Löschen geht, könnte ich mir vorstellen, daß es evtl.
gar nicht sinnvoll ist, Blöcke mit gleichem Inhalt zu schreiben. Egal ob
nun 0x00 oder 0xff. Evtl. wird das einfach nur als eine einzige Zahl
zusammen mit der gewünschten Anzahl gespeichert und löscht dann irgendwas
in der Größenordnung von 3 Bytes auf dem Stick.

Sicheres löschen geht bei USB-Sticks ausschließlich durch vollständige,
mechanische Zerstörung der Chips. Durch überschreiben mit Müll lässt
sich zwar ein Großteil der Daten vernichten, aber eben nicht alle.
Stichwort Overprovisioning.

Komprimierende Controller, die auf das Muster der geschriebenen Daten
reagieren, dürften in USB-Sticks aufgrund deren Wärmeentwicklung eher
selten sein.

Allerdings sind etliche Controller so schlau, den Blockinhalt 0x00 als
unmapped zu speichern - also kein physischer Block zugeordnet. Das
entspricht im Prinzip dem Auslieferungszustand. Dadurch ist das
Schreiben von 0x00 fast so gut wie TRIM. Einziger Unterschied: dabei
/müssen/ die Verwaltungsinformationen sofort geschrieben werden. Bei
TRIM würde eventual consistency reichen. Nur weiß man halt nie, ob der
eigene Controller so tickt. Das ist keine spezifizierte Eigenschaft,
sondern nur eine mögliche Implementierung.

Post by Sebastian Barthel

Post by Marcel Mueller
Bei allem überschreiben sollte allerdings auch klar sein, dass man nur
die logischen Blöcke überschreiben kann, nicht die (zahlreicheren)
physikalischen. Jemand der Böses will, dürfte nahezu sicher noch
Fragmente der Daten in den Chips finden.

Dagegen hilft dann wohl nur sicheres "Zerstören" in Form von Raspel oder
Feuer oder so ...

Bei USB ja. Bei SSD nein - vorausgesetzt der Hersteller hat bei der
Implementierung von Secure Erase nicht betrogen.


Marcel