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 begleitet
werden, sondern still (silent errors) durchgereicht werden.
Also wichtige Daten immer mit Checksummen, Parities oder besser ECC versehen
(z.B. mit par2cmdline)!
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).
Nachtrag 2016: siehe eigene Versuche mit RAID6 auf Sticks.
== 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
bei andauernden Vollschreiben eines 1GB-Sticks mit ca. 5MB/s sind 10e3 Zyklen
nach 23 Tagen und 100e3 Zyklen nach 231 Tagen (0.63 Jahren) erreicht.
1 MB ist bereits nach 5.6h 100e3 mal ueberschrieben (ohne wear-leveling).
Sticks halten den Dauer-Schreib/Lese-Stress ca. 30 Tage stand.
https://www.heise.de/newsticker/meldung/SSDs-sind-oft-robuster-als-versprochen-2234897.html
https://www.heise.de/ct/ausgabe/2017-1-Flash-Speicher-im-Langzeittest-3573503.html
c't 01/2017, S. 100: Langzeitschreibtest 12 250GB-SSDs Jun2016-Dez2016++
Ergebnis: vertragen ueberraschend mehr Schreibzyklen, als gedacht
Dazu meine Anmerkung: ist keinesfalls ueberraschend,
sondern Fehlinterpretation der Ergebnisse.
Zwischen Schreiben und Lesen vergehen etwa 250GB/500MB/s=8.3min,
d.h. Ausfaelle werden erst bemerkt, wenn die Haltbarkeit der Daten
diese 8min unterschreitet. Gewoehnlich erwartet man aber eine
Haltbarkeit der Daten von einem Jahr (JEDEC data retention),
die bei solchen Dauertests nicht gemessen wird.
D.h. erwartete Haltbarkeit der Daten von einem Jahr
wird weit eher unterschritten, als im Dauerschreibtest bemerkt.
Data Retention: Daten-Lebensdauer am Ende der Nutzung, z.B. 1 Jahr nach 3e3(MLC) Schreibzyklen=TBW/capacity
Data Retention: SSDs2017.01: 70TB/250GB= 280 P/E-cycles only!
+Daten-Haltbarkeit Faktor 100 reduziert, wenn bei 75C statt 35C gelagert
daher besserer Test: 3.6Tage bei 75C lagern + verify == 1y 35C
JEDEC.enterprise: 3 months at 40C at EndOfLifetime (in TBW)
JEDEC.consumer: 1 year at 30C after service life (in TBW)
Besserer Test(?): nach x00 Zyklen, bei hoeherer Temperatur z.B. 12h nur lesen
um ca. 1 Jahr bei 20C zu simulieren
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. "
Energieverbrauch von Sticks
Linux on Stick:
- Problem Writespeed Random 4kB sehr schlecht (z.B. rnd-write4k 11kB/s vs. read 10MB/s)
dadurch sysinstallation (auspacken, updates) sehr langsam
- instabiles usb (stick or linux module crashen bei
anstecken/abziehen/datenfehlern/lsusb(?),
reproduzierbar autoreboot nach fsck der root partition on stick),
Abhilfe: ro root oder mini ramdisk + /usr partition oder tinycore like
ToDo:
Langzeitarchivierung: Test geschwaechter Flashs, Eignung, noetige Redundanz
http://en.wikipedia.org/wiki/Low-density_parity-check_code
Wikipedia-Archive mit md5-Summen und ECC-blocks im Langzeittest seit 2016
alte ISOs 1.2GB mit md5/sha1 auf 8GB-stick 2011.02-2016.08 verify=ok
+ 1GB.tar.gpg 2010.12-2016.8 verify=ok
Haltbarkeit: Schreibzyklen (teilweise fertig, redo!), Lesezyklen (s.oben),
Hitze (A/D-Wandler ist T-abhaengig, kurzfristig weniger Fehler bei Erwaermung),
Strahlung(-sdetektor?, A/D-FET killed before high dose charge effects (?))
- write on low temperature below 10C (high resistance Si = low charge (?))
- wait on high temp. (fastest charge loss, p.e. t(25C)=6*t(50C)=50*t(85C))
- read on low temp. (A/D-cuircit has highest-V-threshold)
+ 100e3 reads of 250MB = 250TBR (500MB/s 5e4s=14h) ToDo: 20C vs. 40C?
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)
xorshift-random.c + dd + md5sum + script (2016, einfacher)
Linux:
Bei meinen Tests hatte ich auch Sticks mit Wackelkontakten, dabei
zeigte sich, dass der Linux-USB-Stack (debian 8, CentOS-7) nicht
robust ist. Teilweise haengte sich der USB-port so auf, dass kein
anderes USB-Geraet an dem Port funktionierte, bis der
Rechner rebootet wurde. Neuladen der USB-Treiber oder s2disk (hibernate)
half nicht. Unter Windows passierte das nicht.
Ich vermute, dass der Linux USB Stack nicht gegen USB-Hardwarefehler
robust ist, was bei seriellen Bussen kein Problem sein sollte
(timeouts, 5b/16b-crc-error oder frame-error + counting + Fehlermeldung
+ (optional?) ruecksetzen).
Die Moeglichkeit eines hard-resets durch stromlosmachen der
usb-ports und ruecksetzen der Treiber auf Linux-Ebene auszuloesen
waere fuer unbemannte Systeme sehr nuetzlich.
Leider scheint es fehlt dazu eine Spezifikation.
Es gibt nicht einmal CRC-Error-Counter fuer USB (like edac ce_count),
um Verbindungen auf Fehlerhaeufigkeit zu monitoren.
Uebrigens auch kein parity_error_count oder frame_error_count
fuer einfache serielle Verbindungen wie UART/RS232
(/proc/tty/driver/serial nur fuer echte RS232?).
Hier gibt es genuegend Aufgaben fuer Programierer.