Jörg's Flash-Memory-Tests


Hier folgen ein paar Experimente und Erfahrungen hauptsaechlich zu Flash-Memory (USB-Sticks, 2011) und dessen Haltbarkeit.

Anfang 2011 fragte ich mich, wie gut USB-Sticks ihre Daten halten koennen. Im Netz findet man dazu wenig Experimente. Also habe ich mir eine handvoll alte Sticks genommen, und sie einem Schreibtest unterworfen.
Da es wahrscheinlich trickreiche Firmware gibt, muss man zum effektiven kaputtschreiben von USB-Sticks einiges beachten (Stick einmal befuellen, um ggf. freie Sektoren aus dem Reservepool zu nehmen, komplexe Muster statt reinen 0x00 oder 0xFF verwenden, um ggf. Daten-Kompressionen zu unterbinden). Dann habe ich die Sticks an Ports verschiedener USB-Controller gehaengt, um den Durchsatz zu maximieren und einen kleinen Datenbereich der groesser als ein ggf. vorhandener Cache sein muss mit wechselnden Daten beschrieben und gelesen, bis Datenfehler auftraten und diese analysiert. Da die beschriebenen Sektoren staendig mit den Sektoren aus dem Reservepool wechseln, ist die Zyklenzahl nicht nur von der Flash-Haltbarkeit abhaengig, sondern auch von der Anzahl der Sektoren im Reservepool (dynamisches Wear-Leveling). Dieser Bereich laesst sich ohne Herstellerinformationen nur abschaetzen, und ist etwas kleiner als die Differenz der Stick-Kapazitaet zur naechsten Zweierpotenz (meist ca. 2%). Nur einen kleinen Bereich (ca. 1%) wiederholt zu beschreiben, fuehrt in der Regel (kein statisches Wear-Leveling) etwa 100 mal schneller zu fehlerhaften Flashzellen als den Stick wiederholt komplett zu beschreiben.
Erstes ueberraschendes Ergebnis ist, dass durch extensive Schreibprozesse bearbeitete Sticks allein durch wiederholtes Auslesen Daten vergessen und sich durch Pausen (Abkuehlung?) sogar etwas rueckerinnern koennen (2012-01 auch in http://en.wikipedia.org/wiki/Flash_memory als "Read disturb" als Informationsverlust durch 100000-faches Auslesen der Nachbarzellen ohne regelmaessige rewrites beschrieben). In einigen Faellen konnte man den Stick zig-millionenmal fehlerlos beschreiben, um dann bei einem Lesetest zu bemerken, dass die Daten nur noch Sekundenbruchteile oder wenige Lesezyklen hielten. Ausserdem gibt es furchtbare Firmware, die bei bestimmten Fehlergrad jedweden Datenzugriff oder im guenstigeren Fall nur den Schreibzugriff verweigern. Andere Sticks brachten sporadische Fehler verschiedenster Art. Wichtig ist, dass falsche Bits meist nicht durch Fehlermeldungen begleitent werden, sondern still (silent errors) durchgereicht werden. Also wichtige Daten immer mit Checksummen oder besser ECC versehen. Insgesamt macht die USB-Flash-Firmware im Stress einen eher weniger ausgereiften Eindruck.
Am zukunfttraechtigsten scheinen mir eher primitive Sticks zu sein, die Fehler einfach durchreichen und dann von einem zukuenftigen ECC-faehigen Filesystem korrigiert werden koennen. Transparentes "dynamisches Wearleveling" ist eigentlich kontraproduktiv, da es zum umherwandern der abgenutzten Flashseiten fuehrt. Moeglicherweise werden durch solche Prozesse sogar im Flash abgelegte Firmwaredaten beschaedigt, was eigenartigen Ableben mancher Sticks erklaeren koennte (wer weiss es genau?).
Der Vorteil einer Fehlerkorrektur in Software waere, dass der Nutzer selbst festlegen kann, wieviel Speicheranteil fuer Redundanz verbraucht wird, so dass sich prinzipiell beliebige(???) Schreibfestigkeit einstellen liesse. Alternativ kann das Filesystem schwaechelnde Sektoren aussortieren oder die Daten dort mit mehr Redundanz versehen (schrumpfendes Datenvolumen statt unerkannte Fehler oder Spontanausfall).

 == Stick USB-ID == Fehler nach ... w=Schreibzyklen,r=Lesezyklen,d=Tage =====
   31MB 0ea0:6803  981e3  w256KB                Bitfehler (9d) + Totalverlust (15d) *3 
  123MB 04e8:0110   64e6   w32KB +  4e6 w256KB  Bitfehler + Totalausfall *1 
  123MB 054c:0243  1.8e6 w1024KB +  3e6 w256KB  Bitfehler (20d) *2 
  123MB 0a16:9005  - normale Nutzung -          Datenfehler + permanent read only (?d) 
  125MB 058f:9380  4.7e6  w128KB                Bitfehler (18d) 
  240MB 0d7d:1900   47e6   w16KB                write failed bis reset (70d) 
  240MB 0c76:0005   18e6  w128KB                Bitfehler 
  243MB 0204:6025   20e6    w2KB + 8.8e6 w256KB Bitfehler + Totalausfall (80d) 
  243MB 08ec:0012   37e6   w16KB                Bitfehler (4d) 
  250MB 058f:6387   11e6   w32KB                write failed bis reset (6d), Totalausfall (60d) 
  250MB 0457:0151  4.6e6  w256KB                permanent read only (28h) 
  478MB 090c:1000   33e6  w128KB                I/O-Error on bad block (45d) + Totalausfall 
  991MB 090c:1000  3.6e6 w1024KB                Bitfehler (8d) 
  946MB 08ec:0012  2.6e6    w4KB                Bitfehler (4.4h) 
 1011MB 1307:0163  274e3  w128KB                Bitfehler (2d) + Totalausfall (3d) 
  120MB 1043:8012   77e3  w256KB                Page-Kopien ab 32MB (3h) *4 

 *  KB = 1024B, MB = 1024 KB, 1e3 = 1000, 1e6 = 1000e3
 *1 sporadische I/O-ERRORs an USB2, an USB1 keine Probleme (ca. 3 Monate) 
    zunaechst 2 bad1 bits, nach 1.05e6 r1KB je 1000 bad0 und bad1 bits
    nach weiteren 2.8e6 r1KB Device offlined + rejecting IO
 *2 erste Bitfehler nach Lesetest mit 688e3*r256KB,
    sofortige Schreib/Lesefehler erst nach 58e6 w32KB (32/s, 20 Tage)
 *3 zuerst silent bit errors, nach weiteren 664e3*w256KB 
    I/O-Error + Firmwarereset, Stick hat nur noch 1.75 MB),
    1to0-Bitfehler nach weiteren 6e6 w32KB,
    38 Tage spaeter ca. 1.3% bad Bytes,
    dann nach 1*w + 20e6 * r32KB ohne Fehler I/O-Error + disconnect
    nach physischem reconnect, weiter mit 1.75MB funktionsfaehig
 *4 Adressbereiche erscheinen mit Inhalt anderer Adressbereiche, auch nach
    Neubeschreibung, Pageindex der Firmware nun im defekten Flashbereich?
    normale Nutzung als Blockdevice ueber 32MB nicht mehr moeglich
 ** zum Vergleich Herstellerangaben zu Flash-Ships:
  - 72nm-SLC haelt ca. 100e3 erase-Zyklen, 10y, z.B. blk=32*(512B+16B-ECC) 128MB
  - 72nm-MLC haelt ca.  10e3 erase-Zyklen
 
Sticks halten den Dauer-Schreib/Lese-Stress ca. 30 Tage stand.
Der folgende Plot zeigt, wie ein durch 5 Millionen Schreib- und weitere Lesezyklen geschwaechter USB-Stick durch Dauerlesen zunehmend Bits vergisst:
plot Bit-Fehler versus Lesezyklen
Nach 12-millionen Lesezyklen sind weitere 1000 der insgesamt 4096 1-Bits zu 0-Bits gekippt. Der 1-KB-Block, der vorher mit jeweils 4096 0- und 1-Bits beschrieben wurde, hatte danach somit 25% Datenverlust. Die Dellen in der Grafik sind wahrscheinlich Folgen von Erwaermung und Abkuehlung.
Weitere und detailiertere Ergebniss sollen hier in Kuerze folgen (2012-01).


Links/Weitere Infos:
 http://www.heise.de/ct/artikel/ueberflieger-291740.html
   # erster Test 2006  nach 16e6 Zyklen nicht kaputt
   # zweiter Test 2008 2GB mit 50*full_write+1*md5check, OK nach 12e3 Zyklen
 MLC:  5e6 Zyklen bis Ausfall http://www.hartware.de/report_423_2.html 2010 
 SLC: 50e6 Zyklen bis Ausfall http://www.hartware.de/report_423_2.html 
  Die von Hartware.net "zerschriebenen" USB-Sticks schienen keine solche
  Reserve zu verwenden, denn es wurden mehrere Zellen nacheinander "kaputt
  geschrieben", was immer etwa gleich viele Schreibzyklen brauchte. Haetten die
  USB-Sticks eine Reserve gehabt, waere diese beim Auftauchen des ersten
  Schreib- und Lesefehlers aufgebraucht gewesen und weitere Fehler haetten
  frueher auftauchen muessen. 
 http://www.hartware.de/report_423_3.html
  "Denn bei Flash-Speicher wollen die Zellen alle zehn Jahre aufgefrischt
  werden, sonst verlieren sie ihre Informationen. "
  
ToDo:
 Langzeitarchivierung: Test geschwaechter Flashs, Eignung, noetige Redundanz
   http://en.wikipedia.org/wiki/Low-density_parity-check_code
 Haltbarkeit: Schreibzyklen (teilweise fertig), Hitze, Strahlung(-sdetektor?)
 Zuverlaessigkeit: I/O-Errors, Abstuerze etc., Defektmanagement
 Firmware: usb-pen, mp3-stick 
 alte Festplatten zum Vergleich
 
Software:
  flash_killer.c (30kB, v201101 - v201201, Eigenentwicklung auf Anfrage)

Kontakt? Schau auf meine Hauptseite. Anmerkungen sind willkommen!