Ansicht umschalten
Avatar von hhs
  • hhs

mehr als 1000 Beiträge seit 17.04.2000

Re: Flash ist nicht besonders zuverlässig

foobar schrieb am 12. Juni 2009 00:15


> Das funktioniert nicht:

> - Datenerhalt in Flash-Speichern ca. 10 Jahre.

35 Jahre, allerdings nur in speziellen 256kbit-Serial-Flash-Chips.

Flash-Chips haben zwei schwer zu findende Spezifikationen:

Data Retention Time, d.h. wie lange die Information gespeichert
bleibt, und Endurance, d.h. max. Anzahl von Löschzyklen.

Wikipedia:
...
Verantwortlich für diese begrenzte Lebensdauer ist das Auftreten von
Schäden in der Oxidschicht im Bereich des Floating-Gates, was das
Abfließen der Ladung bewirkt.

> http://de.wikipedia.org/wiki/Flash-Speicher#Nachteile_beider_Architekturen

Die Retention Time gilt wohl nur für neuen Speicher. Da mit
zunehmender Zahl Löschzyklen die Oxid-Schicht geschädigt wird, muß
dadurch auch die Retention Time sinken. Das ist aber schlecht, wenn
der Datenverlust z.B. erst 2 Wochen nach dem Programmieren
stattfindet...

Über diese Zusammenhänge habe ich bisher bei keinem Chiphersteller
Unterlagen gefunden. Wikipedia zitiert da auch nur einen unnützen
c't-Test, denn große Flash-Speicher kann man dank Wear-Leveling in
Tests schlecht an die Verschleißgrenze bringen. Wear-Leveling ist
auch eine undokumentierte Technik, die den Verschleiß gleichmäßiger
verteilen soll. Ein Test, der die Zuverlässigkeit auf Flash-Ebene
bestimmen will, dürfte nicht den kompletten Speicher testen, sondern
nur einen kleinen Bereich, solange, bis der Verschleiß sich zeigt. 

Mein Vorschlag dazu wäre, den Stick vollzuschreiben bis auf einen
Sektor, und nur diesen einen Sektor mit wechselnden Daten zu
beschreiben. Dabei müßte auch die Programmierzeit exakt erfasst
werden, um aus Änderungen auf interne Vorgänge zu schließen
(wachsende Programmierdauer, oder Auswechseln eines Sektors gegen
einen Reservesektor?)

Probleme dabei:
Der USB-Stick enthält einen Speichercontroller, und ein Cache. Der
Test muß das Cache berücksichtigen. Wie läßt sich zuverlässig die
Schreibzeit bestimmen?
- sie müßte mit zunehmendem Verschleiß wachsen, schließlich fließt da
Ladung ja schon während des programmierens ab.
- sie müßte sich deutlich erhöhen, wenn eine defekte Zelle durch eine
Reservezelle ersetzt wird.
- Ein Defekt wird erst festgestellt, wenn alle Reservezellen
verbraucht sind.
Ich las mal in den Spezifikationen eines NAND-Flash-Chips, daß 95%
intakte Blöcke garantiert seien, und vom Stick nur 90% verwendet
werden sollten, und der Rest als Ersatz für defekt werdende Blöcke
dienen sollte. Unter diesen Annahmen wurde dann die Ausfallrate
spezifiziert...

Wear-Leveling: Wenn ich eine Flash-Disk/USB-Stick bis auf einen Block
vollschreibe, und dann nur diesen Block ändere, findet kein
Wear-Leveling statt, nehme ich mal an. Oder es wird tatsächlich ein
wenig benutzter Block in einen viel benutzten umkopiert, bevor der
wenig benutzte dann mit den neuen Daten des vielbenutzten beschrieben
wird. Das würde dann erhöhte Schreibzeit bedeuten.

Während die Zyklenzahl bis zum kompletten Ausfall einer Zelle noch
relativ einfach zu testen ist, dürfte es auf Systemebene aber
ziemlich unmöglich sein, die Datenhaltezeit nach 5000 Löschzyklen zu
bestimmen.
Ich nehme mal an, daß man das bei nackten Chips abschätzen kann, in
dem man hochgenau die Zunahme der Programmierzeit mißt, und daraus
auf den Verschleiß des Gates schließt. 

Also Flash würde ich nur zum kurzzeitigen Datentransport nutzen,
niemals zur Archivierung.

Vor allem, da das bei großen billigeren Speichern eingesetzte
MLC-Flash geringere Retention Time haben dürfte.
Bei SLC wird nur 1 Bit pro Zelle gespeichert, da kann ziemlich viel
Ladung verloren gehen bevor das Bit umkippt, auch müßte die
Komparatorschwelle nicht mittig liegen...
Bei MLC werden bis zu 4 Bit in einer Zelle gespeichert, d.h. Verlust
von 1/32 der Ladung kann, Verlust von 1/16 der Ladung wird ganz
sicher zu einem anderen Bitmuster führen. 

hh

Bewerten
- +
Ansicht umschalten