Hallo zusammen,
ich habe ein Problem mit defekten SD-Karten.
Für einen Datenlogger benutze ich eine SD-Karte ohne Dateisystem. D.h.
ich schreibe Blockweise (512Byte) mit einfach aufsteigender Adresse die
Karte mit Daten voll. Ich benutze eine 4GB Karte, die im Moment nur bis
2GB beschrieben wird und dann wieder von vorne anfängt.
Ich schreibe immer zunächst auf der aktuellen Adresse einen Endblock,
auf der Adresse vorher wird der alte Endblock von den Nutzdaten
überschrieben, so dass ich immer über den letzten Block Bescheid weiß.
Die Daten kommen unregelmäßig, aber nach 4-6 Monaten ist das Ende
erreicht und ich beginne wieder vorne.
Also habe ich etwa (Endblock + Daten etwa 2-3 mal im Jahr) 4-6
Schreibzugriffe im Jahr auf die gleiche Adresse auf die SD-Karte.
Lesezugriffe passieren ständig, da ich die SD-Karte beiläufig noch auf
einem zweiten System spiegele. Aber auch auf dem zweiten System gibt es
die gleiche Anzahl von Schreibzugriffen, da die Blöcke nur geschrieben
werden, wenn die Checksumme nicht übereinstimmt.
Jetzt habe ich das Problem, dass bei mehreren Geräten die SD-Karten
schon nach wenigen Monaten ausgefallen sind. Sowohl auf dem Master- als
auch auf dem Slave-System gab es Ausfälle:
Zum einen gab es eine Karte, die ist noch lesbar über den gesamten
Speicherbereich, aber nicht mehr beschreibbar.
Und es gab mehrere Karten, die sich nur noch bis zu einer bestimmten
Adresse lesen lassen. Interessant ist hier, dass eine Karte auch einen
Defekt in dem nicht benutzten Speicherbereich aufweist.
Da sich die Ausfälle nun häufen, glaube ich nicht an ein zufälliges
Problem.
Haben SD-Karten mit der Art, wie ich sie beschreibe, bzw. lese ein
grundsätzliches Problem? An der reinen Schreibhäufigkeit kann es ja
eigentlich nicht liegen.
Das Master-System ist STM32-basiert, das Slave-System ist
windowsbasiert, es werden also auch unterschiedliche Bibliotheken für
die Kommunikation benutzt, so dass ich auch hier nicht den Fehler
vermute.
Gibt es bei SD-Karten sonstige Restriktionen, die ich nicht kenne, die
man hier unbedingt einhalten muss, um solche Fälle zu vermeiden?
Gibt es bestimmte Kartentypen, die da besser oder schlechter geeignet
sind?
Vielleicht kann mir da jemand weiterhelfen, hierfür schonmal vielen
Dank!
Gruß
Andreas
Andreas schrieb:> Gibt es bei SD-Karten sonstige Restriktionen, die ich nicht kenne, die> man hier unbedingt einhalten muss, um solche Fälle zu vermeiden?
Ja
Habe die umgekehrte Erfahrung gemacht. Datenlogger ohne Filesystem
laufen seit Jahren vollkommen problemlos. Alle 10 Sekunden ein
Schreibzugriff. Die billigsten 4GB Karten bei Reichelt mitbestellt.
RrdTools auf Raspi zerstört die Karten in wenigen Monaten.
Noch einer schrieb:> RrdTools auf Raspi zerstört die Karten in wenigen Monaten.
Kann ich nicht bestätigen gentoo + rrdtools auf ner 16gb SD keine probs,
bei rrdtools ja eh nicht weil die werte immer an einer anderen stelle
der db gespeichert werden wird ja nie jedesmal alle Daten geändert und
nie permanent auf die gleiche stelle.
K. J. schrieb:> bei rrdtools ja eh nicht weil die werte immer an einer anderen stelle> der db gespeichert werden wird ja nie jedesmal alle Daten geändert und> nie permanent auf die gleiche stelle.
kommt auf die größe der RRD an, wenn sie recht klein ist, wird sie
ständig neu geschrieben, weil die werte nachrutschen.
Es handelt sich um normale Consumer-SD-Karten von Transcend.
Habe noch keine anderen ausprobiert, aber wenn ich nach mehreren Monaten
feststelle, die anderen funktionieren auch nicht, bin ich nicht weiter
und habe Monate verschenkt.
Bei begründetem Anlass wäre es natürlich eine Möglichkeit, den
Hersteller zu wechseln.
>nie permanent auf die gleiche stelle
Die Inhaltsverzeichnisse waren hinüber. Datenrettungsprogramm konnte die
meisten Sektoren noch kopieren. Ob fehlerfrei hatte ich nur bei den
Verzeichnissen kontrolliert.
Aber genau dieses Problem kann bei Andreas nicht auftreten.
Ich habe da eine Theorie: die meisten Konsumer-SD Karten verwenden
Multilevelcell FLASH, d.h. es gibt nicht nur H und L, sondern 3 oder
mehr Zustände. Um 4 GB abbilden zu können, reichen also weniger Zellen
aus, die demzufolge öfter als von dir berechnet beschrieben werden. Wie
die Zellen logisch aufgedröselt werden, weiß nur der Hersteller. Dazu
kommt noch erschwerdend, das es ein Übersprechen von benachbarten Zellen
gibt. Bei normalen Zellen hat man 40% sicheren Bereich und 10%
verboteten Bereich. Bei 3 Zuständen sind es nur noch 30% oder weniger.
Wenn man nun 15% Übersprechen zwischen 2 benachbarten Zellen hat (ein
realistischer Wert), dann sieht man schon, das es bei 2 Zusänden
unkritisch ist, bei 3 oder gar mehr Zuständen aber sehr wohl zum Problem
wird. Dazu noch Unterspannung, Ripple oder ein schlechtes Timing oder
ungünstige Temperaturen und die Karte sagt "Nö!"
Andreas schrieb:> D.h.> ich schreibe Blockweise (512Byte) mit einfach aufsteigender Adresse die> Karte mit Daten voll.
Die Erase Sector Size der Karte wird wesentlich größer als 512 Byte
sein. Das heißt für jeden Deiner Schreibzugriffe wird zuerst der
bestehende Erase Sector ausgelesen, dann gelöscht und dann mit den alten
Daten + Deinen neuen 512 Byte gefüllt.
Das Löschen ist das, was das Flash altern lässt.
Klüger wäre es daher, wenn Du nicht in 512 Byte-Blöcken schreiben
würdest, sondern immer in der Größe eines Erase Sectors dieser Karte
(der ist modellspezifisch). Den solltest Du auslesen können (SECTOR_SIZE
(erase sector size) im CSD Register).
Verlasse Dich nicht darauf, daß die Erase Sector Size bei allen Karten
gleich ist, auch wenn das Marketing des Herstellers ihnen den selben
Produktnamen gegeben hat.
Wenn Du die Daten nicht so lange im RAM halten willst/kannst und sowieso
nicht den ganzen Platz auf der Karte verwendest, kannst Du auch immer
nur die ersten 512 Bytes eines Erase Sectors beschreiben, den Rest des
Erase Sectors leer lassen und dann beim nächsten Schreibzugriff beim
nächsten Erase Sector beginnen.
Andreas schrieb:> Es handelt sich um normale Consumer-SD-Karten von Transcend.
Kannst Du denn wirklich sicherstellen, dass es sich um Originalware und
nicht um Plagiate handelt? Gerade bei Speichersticks und -karten gibt es
einen ziemlichen Wildwuchs an Produktfälschern, und ich vermute, dass
auch manch ein ansonsten seriöser Händler auf einen faulen Lieferanten
hereinfallen kann.
Wir haben allerdings auch schon einen Kunden (Industrielektroni) gehabt,
bei dem USB-Speichersticks reihenweise ausgefallen waren. Dies war auf
eine Kombination von Hardware- und Firmwareproblemen zurückzuführen.
Speicherkarten und -sticks sind auch recht pingelig bezüglich des
Temperaturbereichs, gerade im Auto.
Andreas schrieb:> Gibt es bei SD-Karten sonstige Restriktionen, die ich nicht kenne, die> man hier unbedingt einhalten muss, um solche Fälle zu vermeiden?
Ja. Die SD-Spezifikation schreibt bei SDHC (2-32 GB) Karten vor, das
FAT32 -Dateisystem zu benutzen, was du nicht tust. Somit ist das Betrieb
außerhalb der Spezifikation, kann funktionieren, muss aber nicht!
Gerd E. schrieb:> Klüger wäre es daher, wenn Du nicht in 512 Byte-Blöcken schreiben> würdest, sondern immer in der Größe eines Erase Sectors dieser Karte> (der ist modellspezifisch). Den solltest Du auslesen können (SECTOR_SIZE> (erase sector size) im CSD Register).
Bringt leider nichts bei SDHC/SDXC Karten:
"SECTOR_SIZE - This field is fixed to 7Fh, which indicates 64 KBytes.
This value is not related to erase operation. SDHC and SDXC Cards
indicate memory boundary by AU size and this field should not be used."
Die AU Size ist über das SD Status Register auszulesen und beträgt bei
SDHC maximal 4 MB. Am einfachsten wäre es somit, einfach immer 4 MB auf
einen Rutsch zu löschen. Ansonsten stimme ich dir zu dass das löschen an
sich sinnvol ist.
Ich habe gerade mal über den SD-Status die AU-Size ausgelesen, die
beträgt tatsächlich 4MB.
Bedeutet das jetzt, dass ich tatsächlich 8000 Löschvorgänge auf dem
gleichen Löschsektor habe, wenn ich die ersten 4MB mit Blöcken von
512Byte schreibe?
Das würde natürlich Probleme durchaus erklären.
Warum kommt es aber dann vor, dass die ganze Karte nicht mehr
beschreibbar ist und nicht nur bestimmte Blöcke?
Also ich habe jetzt mehrere Karten untersucht, die folgendes
Fehlerszenario haben:
Karte ist grundsätzlich lesbar. Allerdings laufen alle Schreibvorgänge
ins Nirvana. Es gibt keine Fehler der Schreibbibliotheken, also kein
Timeout und nichts, aber die Karte nimmt den Inhalt einfach nicht mehr
an.
Es gibt aber auch Karten, bei denen scheint tatsächlich nur ein
bestimmter Sektor defekt zu sein, bei einer Karte aber
interessanterweise außerhalb des benutzten Bereichs (zumindest bricht
ein Dump immer an der gleichen Stelle ab und das Test-Tool sagt auch,
sie ist an der Stelle defekt)
Sie funktioniert aber im benutzten Bereich einwandfrei.
Andreas schrieb:> Bedeutet das jetzt, dass ich tatsächlich 8000 Löschvorgänge auf dem> gleichen Löschsektor habe, wenn ich die ersten 4MB mit Blöcken von> 512Byte schreibe?
Das hängt stark vom auf der Karte implementierten
Wear-Leveling-Algorithmus ab. Der nimmt an dass in den Sektoren 14354
15368 die FAT kommt. Der dürfte durch das, was du da hin schreibst,
ziemlich verwirrt werden.
Es kann sein dass der Algorithmus beim schreiben das 512 Bytes einen
ganz neuen freien 4 MB Block sucht, die 512 Bytes sowie den Rest des
alten 4 MB Blocks dahin kopiert, und den neuen Block an den alten
"ummappt". Dafür hat die Karte vermutlich ein paar Reserve-4-MB-Blöcke.
Andreas schrieb:> Warum kommt es aber dann vor, dass die ganze Karte nicht mehr> beschreibbar ist und nicht nur bestimmte Blöcke?
In den Karten arbeitet eine komplexe Firmware, es lässt sich schwer
sagen warum die sich unter welchen Bedingungen wie verhält!
Andreas schrieb:> Ich schreibe immer zunächst auf der aktuellen Adresse einen Endblock,> auf der Adresse vorher wird der alte Endblock von den Nutzdaten> überschrieben, so dass ich immer über den letzten Block Bescheid weiß.
Machst du das sequentiell? Also überschreibst du zuerst den Endblock und
schreibst dann den neuen Endblock oder umgekehrt? Passiert das mit zwei
Single Sector Write commands oder mit einem Write Multiple command?
Am besten wäre auf jeden Fall ein sequenzieller Zugriff mit einem Write
Multiple command.
Das schreiben von so kleinen Sektoren ist wie bereits erwähnt wurde
suboptimal. Ein Flash kann nicht beliebig oft gelöscht werden, weil die
Zellen bei dem Löschen beschädigt werden. Die kleinste Einheit die auf
dem Flash gelöscht werden kann dürfte um die 4MiB liegen, möglicherweise
noch grösser.
Bei einem MLC Flash kann ungefähr 2000-3000 mal gelöscht werden, wenn es
eine TLC Karte ist noch weniger.
Je nach dem wie gut die Karte einen Zugriff optimieren kann, muss er
intern mehr oder weniger löschen. Bei 4MiB grossen Löscheinheiten (ich
nenne diese mal Blöcke) und einer 4GB Karten ergibt das 1024 solche
Blöcke.
1024 Blöcke die jeweils 3000 mal gelöscht werden können sind etwas mehr
als 3 millionen löschvorgänge.
Du schreibst, dass du 6 Monate lang hast um 2GB mit 512byte Zugriffen zu
füllen, das sind 2GB/512 = etwas unter 4 mio. Zugriffe.
Jetzt ist es nicht unbedingt übertrieben bei solch keinen Zugriffe, je
nach dem davon auszugehen dass ein Zugriff etwa einen Block erase zur
folge hat.
Das ganze haut also etwa hin wuerde ich sagen. Kommt noch etwas darauf
an wie genau das geschrieben wird (Siehe Eingangsfrage).
Ich würde empfehlen die Zugriffe auf die Karte möglichst Sequenziell zu
halten und noch wichtiger, in möglichst grossen Zugriffen die möglichst
auch auf den 4MiB Grenzen zu liegen kommen.
Uebrigens: Die Logische Adresse der Daten lässt keinen Rückschluss
darauf zu wo die Daten auf dem Flash phasikalisch liegen.
Oder du besorgst dir eine SLC Karte die etwas mehr aushällt ;)
Gruss
Andreas schrieb:> Bedeutet das jetzt, dass ich tatsächlich 8000 Löschvorgänge auf dem> gleichen Löschsektor habe, wenn ich die ersten 4MB mit Blöcken von> 512Byte schreibe?
Nur als Idee:
Kannst du nicht immer einen 4-MB-Block auf einmal löschen (CMD38), und
den dann nach und nach befüllen?
Wenn die Kartenfirmware nicht ganz dumm ist, bleibts dann in der Summe
bei einem Löschvorgang pro beschriebener Zelle.
Andreas schrieb:> ich habe ein Problem mit defekten SD-Karten.
[kompetente Beobachtungen in fehlerfreier deutscher Sprache
dargestellt->Gott sei Dank: endlich mal kein Troll]
> Zum einen gab es eine Karte, die ist noch lesbar über den gesamten> Speicherbereich, aber nicht mehr beschreibbar.> Und es gab mehrere Karten, die sich nur noch bis zu einer bestimmten> Adresse lesen lassen. Interessant ist hier, dass eine Karte auch einen> Defekt in dem nicht benutzten Speicherbereich aufweist.
Tja, das ist Kapitalismus in Reinkultur. Irgendwie muss ja der geringe
Preis zustande kommen, für den du die Karten gekauft hast.
Und so funktioniert das: es wird der billichste Scheiß an zukaufbarer
Hardware (also der eigentliche Flash) reingewürgt und dann auch noch
Lizenzkosten beim Controller gespart. Im Extremfall z.B. durch komplette
Abwahl aller Datensicherheitskonzepte, die der Flashcontroller bieten
könnte. Der Firmware-Blob für den Controller enthält also im
Extremfall nicht viel mehr als einen simplen 1:1-Mapper. Das ist für den
Einkäufer gleich doppelt attraktiv. Erstens werden teure Lizenzkosten
für Firmware gespart und zweitens steht mehr von der Flash-Bruttokapizät
auch netto "zur Verfügung" des Anwenders. Naja, immerhin bis zum ersten
Fehler...
Dann kommt nämlich das endgültig perfide: Einige der
Flash-Controllerhersteller haben auch erkannt wie der Kapitalismus
funktioniert und wollen wiederum ihre Kunden dazu bringen, möglichst
viel bei ihnen zu kaufen, hier also Lizenzen für bestimmte
Firmware-Features.
Sie versuchen das, indem sie die Kunden der Kunden ihrer Daten berauben.
Statt also nach Feststellung eines Fehlers nur den Schreibzugriff zu
sperren, wird ab Fehler auch jeder Lesezugriff abgewiesen.
Tja, der Kapitalismus ist schon die wirklich überlegene
Gesellschaftsordnung. Und du spielst zumindest insofern mit, indem du
immer den billichsten Scheiß kaufst...
c-hater schrieb:> Sie versuchen das, indem sie die Kunden der Kunden ihrer Daten berauben.
Das ist die einzige Möglichkeit, um die gespeicherte Datenmenge
langfristig im Griff zu behalten.
