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
Welche Karten verwendest du? Sieht nicht gerade nach Industriequalität aus.
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.
Hier kann man prüfen, ob die Transcend Karten Originale sind: http://de.transcend-info.com/support/verification
Hast Du auf beiden Systemen die gleiche Anzahl Lesezugriffe? Wenn ja, wieviele pro Sekunde/Minute?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.