Raspberry Pi SD Karten Korruption vermeiden - Geheimnisse der microSD Karte

Ein wesentliches Kernelement einer Raspberry Pi Lösung - ob im Einsatz als RetroPie, um alte Spiele zu spielen, oder in industriellen Signage-Anwendungen (informative Anzeigen für Kunden, beispielsweise in Schaufenstern) - ohne die microSD Karte läuft der Raspberry Pi nicht. Egal, ob Pi 3, Pi Zero W, oder Raspberry Pi Model B+.(*)

Die microSD Karten stehen mittlerweile in beeindruckenden Kapazitäten von bis zu 256 GB zur Verfügung. Jede microSD Karte findet selbst in der Hand eines Babys gut Platz. Um diese Datenmenge allerdings auf Papier auszudrucken würde man 10.000 stattliche Bäume benötigen.

Ich gebe in diesem Artikel einen in-depth Überblick über die Funktionsweise von Speicherkarten, und Tipps um die Langlebigkeit der Karte zu erhöhen.

Grundlagen: Im Inneren der microSD-Karte

Inneres einer microSD Karte

Bild: Illustration des Inneren einer SD Karte. Die microSD Karte ist analog aufgebaut. Bildquelle: CC-BY-SA Korpsvart, Wikimedia Commons

Die microSD Karte enthält einen Flash-Speicherbaustein (links auf dem Bild), und einen Micro-Controller (rechts auf dem Bild, meist auf ARM Basis).

Flash

Flash-Speicher speichert Informationen durch "gefangene" Elektronen, die über eine hohe Spannung durch einen Nichtleiter hindurch in ein sogenanntes Floating Gate "injiziert" werden(**). Die Elektronen sind damit Teil eines Transistors, der je nach Ladung des Floating Gates einen angeschlossenen Strom fließen lässt, oder auch nicht. Sie können theoretisch nicht abfließen, da das Floating Gate elektrisch isoliert ist. Dadurch bleibt die Information auch nach Abschalten der Stromzufuhr erhalten.

 Floating Gate Schaltbild

Bild: CC-BY-SA Д.Ильин Wikimedia Commons /  Jlochoap CC-0

Gelesen werden die Informationen immer zwischen Source (S) und Drain (D). In das floating Gate eingebrachte Elektronen erhöhen dabei z.B. die Schwellspannung des Transistors, ab der Strom fließen würde. Der Transistor sperrt dann bei einer normalen Lesespannung (leitet nicht).  

Zur Programmierung des Floating Gates werden deutlich höhere elektrische Spannungen (z.B. 10 V) genutzt als für den normalen Lesebetrieb (z.B. 3,3 V).  Dazu wird zusätzlich das Control Gate (V1/V2/V3) verwendet. 

Zum Löschen werden die Elektronen durch Anlegen einer hohen negativen Spannung über das Control Gate wieder aus dem Floating-Gate ausgetrieben.

NAND-Flash Bausteine, die in microSD Karten eingesetzt werden, gruppieren die einzelnen Speichertransistoren zu Pages, und mehrere der Pages zu Blöcken. Eine Page hat dabei zwischen 512 bis 8192 Bytes, ein Block kann bis zu 256 Pages enthalten (damit insgesamt 2048 kB bei 8kB Pagegröße).

Beschreiben (mit einer logischen "1") kann bitweise oder zumindest byte / wordweise erfolgen. Löschen (auf eine logische "0") kann aber nur blockweise erfolgen  Nicht geänderte Informationen müssen dabei trotzdem noch einmal einprogrammiert werden.

Flash Speicher haben durch das Programmieren und Löschen eine begrenzte Lebensdauer, die in Löschzyklen angegeben wird. Der Grund für die begrenzte Lebensdauer sind durch die hohen Spannungen entstehende Schäden an der isolierenden Oxidschicht, die das Floating-Gate vor Abfluß der Ladung schützt. Sobald diese Schicht leitend wird, kann keine Information in der Speicherzelle mehr gehalten werden.

Ausblick: Multi-Level-Cell Speicherzellen

Anfangs gab es nur zwei Ladungszustände (1 Bit Information) je Speicherzelle. Inzwischen werden dank mehrerer Floating Gates je Transistor  bei Multi-Level-Cell-Speicherzellen unterschiedliche Ladungszustände, und damit mehrere Bits pro Speichertransistor gespeichert. Der Transistor leitet den angelegten Strom dann also unterschiedlich gut weiter, was beim Auslesen ausgewertet wird.

Dadurch lässt sich einerseits die Dichte der Speicherzellen sehr gut erhöhen, andererseits erfolgt das Auslesen langsamer, und die Speicherzellen reagieren deutlich empfindlicher mit Bitfehlern auf Ladungsverluste. Bei Single Level Cells sind damit 100.000 bis 1.000.000 Schreib-Lösch-Zyklen möglich, bei TLCs (Triple-Level-Cells mit drei Bits je Speicherzelle) ca 1000 Schreib-Lösch Zyklen. 

Der Controller

Die Aufgabe des Controllers ist den Flash zu verwalten, und dabei insbesondere Wear Leveling und Lese-Fehlerkorrekturen durchzuführen. Die Performance und Langlebigkeit der microSD Karte hängt ganz entscheidend von den im Controller eingesetzten Algorithmen ab. 

Flash-Speicher lässt sich  durch Schäden an der isolierenden Oxidschicht der Floating Gates wie oben beschrieben nicht beliebig oft neubeschreiben. Um Schäden an einzelnen besonders häufig genutzten Bereichen zu vermeiden, variiert der Controller die physikalische Zuordnung zu den logisch vom Dateisystem adressierbaren Blöcken (= Wear Leveling). 

Bereits im Auslieferzustand sind defekte Blöcke (bad blocks) im Flash-Speicher vorhanden. Diese defekten Blöcke werden in einem speziellen Bereich des Flash-Speichers markiert.

Ebenso verwaltet werden Fehlerkorrektur-Informationen zu einzelnen Blöcken, damit Lesefehler durch Checksummen korrigiert werden können. Der Controller fügt die Blöcke mit gehäuft auftretenden Lesefehlern zu der Liste von Bad Blocks hinzu, und verschiebt die physikalische Zuordnung des logischen Blocks. 

Die microSD Karte hat - je nach Hersteller - typischerweise ca. 10 % Kapazitäten um die Bad Blocks mit guten "Reserve-Blocks" abzufangen.

Dirty little secrets: Probleme von Flash Speicher

Nur Blockweises Löschen

Daten gelöscht können nur blockweise gelöscht werden. Das Löschen belastet die Speicherzellen, und verkürzt ihre Lebensdauer - es entstehen neue Bad Blocks.

Defekte Blöcke ab Werk

Die Flash-Speicher werden bereits bei Auslieferung mit defekten Blöcken ausgeliefert. Im Laufe des Betriebes kommen weitere defekte Blöcke (bad blocks) hinzu. Der Controller versucht durch Wear-Leveling Blöcke daher möglichst gleichmäßig verteilt zu beschreiben / löschen. 

MLC und TLC besonders empfindlich

Durch Multilevel-Cell-Speicherzellen (MLCs) ist die Zahl der Löschzyklen, und damit die Langzeit-Zuverlässigkeit reduziert. 

Read Disturb

Ein bisher noch nicht von mir erwähntes, aber besonders perfides, Phänomen ist Read Disturb. Selbst bei ausschließlichem Lesen von der Karte kann es - gerade durch das Lesen - dazu führen, dass benachbarte Speicherzellen im selben Block ihre Programmierung ändern. Die Wahrscheinlichkeit dass das passiert steigt stark nach einigen 100.000 Lesevorgängen.

Um Read Disturb zu vermeiden protokolliert der Controller daher die Zahl der Zugriffe auf einen Block, um ihn bei Überschreiten einer Schwelle am Stück an einen neuen Ort zu kopieren, und den Originalblock zu löschen. Danach kann der Block erneut "wie neu" verwendet werden.  

All diese Dinge muss ein Controller kompensieren, um uns nach außen hin eine "perfekte Speicherkarte" vorzutäuschen, während es im Inneren alles andere als perfekt aussieht!

Last but not least könnten durch Röntgenstrahlen geschriebene bits unabsichtlich gelöscht werden. Hier kann nur ein Röntgen-sicheres Design der Karte sicherstellen, dass die Daten intakt bleiben. 

Hersteller & Auswahl einer guten Karte

Sowohl Micro-Controller und Flash-Baustein als auch die fertige microSD Karte können von verschiedenen Herstellern kommen - die Panasonic SD Karte im Beispielfoto hat Samsung-Flash, und der Controller wurde in Japan hergestellt.

NAND-Flash-Bausteine werden von vier Herstellern produziert:

  • Samsung <- Marktführer
  • Toshiba
  • IM Flash Technologies (Micron Technology & Intel Joint Venture)
  • Hynix in Kooperation mit Numonyx

Toshiba und Samsung stellen den Großteil aller Chips her.

SanDisk

SanDisk und Toshiba haben ein Joint Venture für Flash-Herstellung. SanDisk hat allerdings 2009 die Rechte an den Fabriken an Toshiba übertragen, um ein Fabless Flash Memory Hersteller zu werden. Die Entwicklung der Speicher erfolgt nach wie vor zusammen. SanDisk und Toshiba sind zusammen mit Matshushita die Begründer des SD Standards, 1999. Auch der microSD Standard wurde von SanDisk eingeführt. 

Wir setzen seit längerem auf die Marke SanDisk, und haben damit bisher sehr gute Erfahrungen gesammelt. 

Samsung

Ebenfalls häufig empfohlen werden Samsung Speicherkarten. Als Marktführer im NAND-Flash Bereich kann Samsung den gesamten Aufbau der SD-Karte aufeinander abstimmen, und verfügt über alle nötigen Informationen für ein solides Produkt. 

Kingston

Wir haben mit der Zuverlässigkeit von 128 GB Kingston-Karten in einem kritischen Projekt schlechte Erfahrungen gesammelt. Kingston verfügt über keine eigenen Fabs, und kauft Überkapazitäten anderer Flash-Hersteller auf. Dadurch kann keine konsistente Performance garantiert werden. 

Interessant ist in dem Zusammenhang auch der folgende Artikel von Bunny Huang.

Toshiba

Toshiba, als die #2 im weltweiten DRAM Markt hat auch eigene Speicherkarten-Produkte. SanDisk und Toshiba sind zusammen mit Matshushita die Begründer des SD Standards, 1999. Wir haben mit Toshiba Karten bislang noch keine Erfahrungen. 

Transcend / Silicon Power

Ebenfalls verwendet - gerade im Low-Cost Bereich - haben wir Transcend und Silicon Power Karten. Die Karten sind grundsätzlich gut, gefühlsmäßig haben wir bei Transcend jedoch höhere Retouren / Defekte als bei SanDisk gesehen. Für kritische Projekte würde ich daher eher SanDisk / Samsung empfehlen. 

Auswahl einer guten Speicherkarte

Um eine gute Speicherkarte auszuwählen gilt es also zunächst den Hersteller auszuwählen. Wir empfehlen Samsung oder SanDisk, evtl. auch Toshiba in die engere Auswahl zu nehmen. 

Als nächstes sollte die Speicherklasse beachtet werden. Class 10 ist dabei die schnellste am Raspberry Pi aktuell "verwertbare" Klase, da die microSD Schnittstelle am Pi von der Geschwindigkeit her limitiert ist. Diese Klasse bezeichnet die schnellste Schreibgeschwindigkeit blockweise. Es handelt sich dabei nicht um die Schreibgeschwindigkeit für verstreute Random-Access-Writes, die in realen Anwendungen aussagekräftiger ist.

Eine höhere Klasse ist teurer, aufgrund der deutlichen Performancesteigerung jedoch empfehlenswert. Wir liefern üblicherweise Class 10 Karten aus. 

In dieser Übersicht auf eLinux.org kann dann eine geeignete Speicherkarte auf Kompatibilität mit dem Raspberry Pi geprüft werden. Wichtiger Hinweis: die Raspberry Pi Firmware wurde mehrfach modifiziert, um eine bessere Kompatibilität mit Speicherkarten herzustellen, und Datenkorruption zu vermeiden.

Bestellen sollte man von vertrauenswürdigen Quellen - wir beziehen unsere SanDisk microSD Karten beispielsweise direkt von der Raspberry Pi Foundation, und renommierten, großen deutschen Distributoren. Auf Amazon sollte man darauf achten direkt von Amazon zu bestellen, nicht von einem Marketplace-Händler. 

Bestimmte Informationen (cid, csd, Datum, manfid, oemid, serial) der microSD Karte können mit Linux ausgelesen werden, um zu prüfen dass man den korrekten Hersteller erhalten hat. Beispiele mit einer Transcend Karte:

cd /sys/class/mmc_host/mmc?/mmc?:*
echo "man:$(cat manfid) oem:$(cat oemid) name:$(cat name) hwrev:$(cat hwrev) fwrev:$(cat fwrev)"

man:0x000074 oem:0x4a60 name:USD   hwrev:0x1 fwrev:0x0

echo "serial:$(cat serial) mdt:$(cat date)"

serial:0x401e39f2 mdt:03/2017

Die Manufacturer ID (manfid) wird von der SD-3C LLC zugewiesen, ebenso die OEM / Application ID (oemid). Die oemid identifiziert den OEM der Karte und/oder den Inhalt der Karte. 

Der Produkt Name (name) ist 5 Zeichen lang (ASCII). hwrev ist die Hardware Revision, und fwrev die Firmware-Revision. Zusammen sind sie die Product Revision (hwrev.fwrev).

Die serial ist die Seriennummer der microSD Karte, es ist ein 32bit-Feld das als unsigned integer ausgelesen werden sollte.

Die mdt (Manufacturing Date) gibt an, wann die Karte hergestellt wurde - Jahr und Monat.  

 

Die Werte können mit den Werten auf Webseiten abgeglichen werden, um Betrug durch gefälschte microSD Karten aufzudecken. Ich empfehle dazu die Lektüre von Bunny's Blog-Artikkel (eins)  und diesem Artikel (zwei). 

Stabile man/oem Kombinationen einer Marke weisen auf eine gut kontrollierte und gleichmäßige Lieferkette hin. SanDisk hat beispielsweise bei allen Einträgen im eLinux.org Wiki folgende Kombination: man:0x000003 oem:0x5344. Andere Marken wie zum Beispiel Transcend variieren ihre Lieferanten, dadurch kann eine gleichbleibende Qualität nicht mehr garantiert werden.

 

Datenkorruption im Betrieb vermeiden

Die microSD Karte ist die "Festplatte" des Raspberry Pi's. Mit einer normalen Linux-Konfiguration wird sie genau so behandelt - es erfolgen sowohl Lese- als auch Schreibzugriffe. Linux loggt viele Protokolldateien, und aktualisiert unter anderem auch die Zugriffszeiten auf die Dateien. Daten werden also häufig geändert und überschrieben. Dafür sind microSD Karten an sich nie ausgelegt worden.

Tipp #1: Raspberry Pi ordnungsgemäß herunterfahren & Gutes Netzteil

Einen Windows-Rechner würde man auch nicht einfach vom Strom ziehen. Bei Linux-Rechnern, und insbesondere den microSD Karten-gestützten Raspberry Pi's ist es bei Powercuts nur eine Frage der Zeit bis es zu Datenkorruption kommt. 

Linux hat Lese-Schreibcaches, um Dateioperationen zu beschleunigen. Bei Ziehen von Strom verliert man u.U. die Informationen in den Schreibcaches, die noch nicht auf die microSD geschrieben wurden. 

Wie bereits erwähnt schiebt der microSD außerdem Controller zur Laufzeit im Sinne des Wear-Leveling, und Vermeiden von Read Disturb Daten hin und her. Das geschieht ohne Wissen des Linux-Systems ("transparent"). Und je nach Hersteller mehr oder weniger konservativ. Auch hier können - insbesondere während Schreibvorgängen! - Datenschäden und Verluste auftreten.

Man sollte also daher nach dem Herunterfahren darauf achten, dass die ACT-LED des Raspberry Pi aufhört zu blinken, und erst danach den Strom ziehen.  

Ein schlechtes Netzteil kann genauso zu Problemen durch Brownouts (Unterspannung) führen. Im Zweifelsfall sollte das von der Raspberry Pi Foundation empfohlene Stontronics Netzteil eingesetzt werden:

Tipp #2 Read-Only System mit Overlays

Zwar schützt ein Read-Only System die SD Karte nicht von Read Disturb, und damit eingehend durch die nötigen Löschzyklen vor einer Alterung. Jedoch erfolgt diese deutlich langsamer, als wenn man aktiv schreibt.

Ein Read-Only Dateisystem hat auch weitere Vorteile, beispielsweise weniger Dateisystem-Checks beim Start.

Gerade embedded Systeme - d.h. Systeme die für einen bestimmten Zweck entwickelt worden sind, und dann verbaut in eine Anwendung eingesetzt werden (z.B. Digital Signage) benötigen nicht unbedingt die Möglichkeit ständig neue Software aufzuspielen, und präzise Logs vor Ort zu halten. Die Logs können (ggf. zeitversetzt) über das Netzwerk an einen zentralen Server geschickt werden, und für Systemupdates kann das System in einen maintenance Modus gesetzt werden, um die Updates einzuspielen. 

Hier sind einige Informationen aus dem Debian Projekt, auf dem Raspbian basiert: https://wiki.debian.org/ReadonlyRoot

Mit Hilfe von RAM-Disk Overlays (im tmpfs) kann ein System trotzdem Log Dateien schreiben, oder Änderungen an Dateien vornehmen. Die RAM-Disk Overlays könnten periodisch mit speziell dafür vorgesehenen Partitionen auf der SD Karte synchronisiert werden. Aufpassen muss man bei der RAM-Disk dass sie nicht überläuft (aufgrund der Log-Dateien), und es steht natürlich weniger RAM-Speicher für normale Tätigkeiten zur Verfügung.

Wir nutzen diese Technik bei unserem Produkt Anonymebox, bei dem davon ausgegangen werden muss dass die Nutzer sie einfach von der Steckdose abziehen. 

Tipp #3 Reduktion von Schreibvorgängen

Gerade bei älteren Kerneln updated Linux gemäß dem POSIX Standard bei jedem Zugriff auf die Datei die Zugriffszeit. Das heißt jeder Lesevorgang zieht automatisch einen Schreibvorgang nach sich. Es gibt die Möglichkeit explizit in /etc/fstab noatime zu setzen, falls das nicht schon gesetzt ist (Raspbian setzt es anscheinend bereits automatisch).

Weitere Informationen zu relatime und noatime

Systemlog disablen mittels mask:

systemctl mask systemd-journald.service
Created symlink from /etc/systemd/system/systemd-journald.service to /dev/null.

sudo systemctl mask rsyslog.service
Created symlink from /etc/systemd/system/rsyslog.service to /dev/null.

Weitere von anderen Anwendungen erstellte Logs, und die Folgen des disablen dieser Services (bspw. dass bestimmte Dienste nicht mehr starten) sollten natürlich genau im Detail untersucht werden. 

Swap Datei:

Falls der RAM nicht ausreicht, verschiebt Linux einzelne RAM-Bereiche in eine SWAP Datei. Mit dem folgenden Befehl kann der Status der SWAP Datei geprüft werden:

sudo systemctl status dphys-swapfile 
● dphys-swapfile.service - LSB: Autogenerate and use a swap file
Loaded: loaded (/etc/init.d/dphys-swapfile)
Active: active (exited) since Sat 2017-07-01 19:11:57 UTC; 8min ago
Process: 498 ExecStart=/etc/init.d/dphys-swapfile start (code=exited, status=0/SUCCESS)

Mit dem folgenden Befehl kann SWAP abgeschaltet werden:

sudo systemctl disable dphys-swapfile

Dieser Artikel gibt einige weitere interessante Tipps. (Achtung: für Raspbian Wheezy geschrieben, aktuell ist Jessie mit weitreichenden Änderungen - insbesondere den Symlink im Artikel empfehlen wir NICHT zu setzen)

Fazit

MicroSD Karten stellen die Langzeit-Zuverlässigkeit von Raspberry Pi basierenden Systemen im Dauereinsatz auf eine schwere Probe.

Durch den Einsatz des richtigen Netzteils, read-only-Systemen mit Overlays, konsequente Reduktion von Schreibvorgängen, und Auswahl einer guten Marken-SD Karte kann die Stabilität auf Dauer erhöht werden. 

Anmerkungen

(*) Anmerkung: der Raspberry Pi 3 kann von USB-Medien, oder über Netzwerk (Ethernet) booten, ohne microSD Karte.

Vor allem für einen Boot über Netzwerk wird dennoch empfohlen, eine microSD Karte mit einer speziellen Firmware zu installieren, da im Bootcode ein Timeout-Bug eine stabile Boot-Funktion verhindert.

Die Ausführungen oben über den Aufbau von Flash-Speicher treffen auch auf USB-Sticks zu, da darin ebenfalls Flash Speicher verbaut wird.

(**) Anmerkung: eine zunehmend eingesetzte Alternative zu Floating Gates sind Charge Trapping Flashspeicher, das Funktionsprinzip bleibt gleich. Die Charge-Trap Flashzelle ermöglicht höhere Speicherdichten.

ControllerErklärungErläuterungFlashIn-depthInfoMemoryMicrosdPi zero wSd karteSpeicherTransistor

4 Kommentare

Max (buyzero.de)

Max (buyzero.de)

@Tobias: ja, SLC sind deutlich robuster und sicherer. AFAIK sind sie ca. zwei – drei mal teurer als die MLC Karten (aber ohne Garantie :-)!).
Ja, die SanDisk und alle anderen normalen Karten sind MLC.

Ich habe keine Karten in den Test aufgenommen, da ich bislang noch keine solchen Karten für Projekte eingesetzt hatte. Für ein Industrie-Kundenprojekt setzen wir stattdessen auf unser Pi Carrier Control Board, das auf dem Compute Module aufbaut, und damit auf eMMC Flash. Das scheint mir insgesamt die solidere Variante (auch mechanisch!) als SLC SD Karten.

Bei kritischen Projekten würde ich immer auf das Compute Module gehen. Bei weniger kritischen tun es vielleicht auch read-only Dateisysteme.

@All: Wir beraten Sie gerne in diesem Bereich rund um Raspberry Pi Lösungen für Ihr Projekt:
https://buyzero.de/pages/kontakt

Frank

Frank

Mein Fazit ist, ein Raspberry Pi mit SD-Karte ist für einen produktiven Einsatz (z.B. Smarthome wie OpenHab usw.) nicht zu gebrauchen. Das muss man mal deutlich sagen. Was mich das schon an Zeit und Nerven gekostet hat. Ich nutze nur noch Pi + SSD – alles andere nur noch zum rumspielen.

Tobias

Tobias

Klasse Artikel. Hat mir sehr weitergeholfen. Einen Sachverhalt habe ich entweder nicht verstanden, oder er ist in Eurem Artikel nicht berücksichtigt:

Wenn ich es richtig verstanden habe, sind SLC (Single Level Cells) deutlich robuster und sicherer als die ganzen handelsüblichen Consumer SD-Karten mit MLC-Technik (darunter fallen ja auch die normalen Sandisk, oder?), da diese ca. um das 10-Fache mehr an Schreibvorgängen zulassen. Aus welchem Grund habt Ihr in Eurer Auflistung der Hersteller und Modelle keine SLC-Speicherkarten in den Test aufgenommen? Für viele Projekte ist der Preis eventuell gar nicht entscheidend, sondern die Sicherheit. Vor allem stellt sich ja auch noch die Frage über welchen Preisunterschied man spricht. Rein theoretisch kann man ja sogar den 10-fachen Preis zahlen und es würde sich rechnen. Ich würde mich sehr freuen, wenn es hierzu noch eine Ergänzung geben könnte.

Eugen

Eugen

Danke, habe einige neue und nützliche Sachen aus diesem Artikel gelernt!

Hinterlasse einen Kommentar

Alle Kommentare werden vor der Veröffentlichung moderiert