Hallo. Ich verwende auf meinem PIC32 eine SD-Karte mit FAT32. Um mein System möglichst gut gegen Datenverlust abzusicheren, muss ich herausfinden, welche Operationen zu Datenverlust führen können. Beim Lesen kann ja nichts passieren, beim Schreiben siehts aber anders aus. Wichtig wäre für mich, dass bereits geschriebene Daten auf keinen Fall verloren gehen. Neu zu schreibende Daten werden zusätzlich auf einem SRAM zwischengespeichert. Die wichtigste Frage zuerst: Kann das Dateisystem zerstört werden, wenn in einem ungünstigen Zeitpunkt die Spannung ausfällt? Und wenn ja, welche Operationen sind hier kritisch? Dateien die nicht schreibend geöffnet sind, werden durch einen Spannungsausfall nicht beeinflusst oder? thx
Es gibt SD-Karten welche nur 1 mal beschreibbar sind. D.h. einmal geschriebenes kann nicht mehr gelöscht werden. Man kann nur hinzufügen. Weiß aber nicht was die kosten. Ansonsten schau mal wie Journaling File Systeme das so machen. Da wird jede Ändernung als Logeintrag vorgehalten. Hat Vorteile bei solchen kritischen Situationen wie Stromausfall beim schreiben. gruß cyblord
Wenns das Budget zulässt nen kleinen Goldcap in die Schaltung und detektieren wann die Versorgung ausfällt. Dann schnell auf die Karte schreiben und schlafen legen.
fat schrieb: > Dateien die nicht schreibend geöffnet sind, werden durch einen > Spannungsausfall nicht beeinflusst oder? Bei Flash-Medien ist die Sache etwas komplizierter, da dessen Daten nicht direkt überschrieben werden. Sondern es werden grosse Blöcke (0,5MB oder so) in einen neuen vorher gelöschten Block kopiert und dabei die Daten in der Kopie geändert. Und zwar auch dann, wenn nur ein einziger Sektor geändert werden soll. Da sind folglich auch eigentlich unbeteiligte Daten dabei. Entscheidend ist hier also, dass der Controller der SD-Karte die dafür erfolderlichen internen Metadaten gegenüber einem Stromausfall zu jedem beleibigen Zeitpunkt so narrensicher verwaltet, dass stets entweder ein alter oder ein neuer konsistenter Stand entsteht und diese Metadaten nie verloren gehen. Da diese Aktion aber innerhalb der SD-Karte stattfindet, ist das kaum irgendwie ermittelbar, es sein denn auf Anfrage beim Hersteller. Angesichts des typischen Marktes von SD-Karten würde da auch nicht unbedingt meine Daten drauf verwetten wollen. M.a.W: Stell sicher, dass du beim Stromausfall garantiert alles loswirst, bevor entgültig Schicht im Schacht ist. Und nimm keine klassischen Panasonic Goldcaps, weil die nicht annähernd genug Strom fürs Schreiben/Löschen von Flashmedien liefern.
Also einen Bufferkondensator habe ich bereits vorgesehen. Der reicht jedoch nur für ein paar ms. Die file-Operationen dauern aber alle ziemlich lange. Meine Idee wäre es, die kritischen Befehle zu finden und diese dann absichern. Daten die gerade geschrieben werden sind kein Problem - wenn diese verloren gehen, liegen sie immer noch auf der SD-Karte. Bereits gespeicherte Daten müssen aber erhalten bleiben. Bring hierfür der Einsatz von Industrie SD-Karten etwas?
Ein Ansatz wäre ein FRAM an Stelle des SRAM Puffers. Die Dinger sind nichtflüchtig, genauso schnell wie SRAM, und bei kontrolliertem Verhalten des sie ansprechenden µCs ziemlich narrensicher.
fat schrieb: > Also einen Bufferkondensator habe ich bereits vorgesehen. Der reicht > jedoch nur für ein paar ms. > Die file-Operationen dauern aber alle ziemlich lange. > Meine Idee wäre es, die kritischen Befehle zu finden und diese dann > absichern. > > Daten die gerade geschrieben werden sind kein Problem - wenn diese > verloren gehen, liegen sie immer noch auf der SD-Karte. > Bereits gespeicherte Daten müssen aber erhalten bleiben. Also wenn du alle Daten immer Blockweise schreibst (also immer nur dann wenn ein ganzer Block Daten vorhanden ist), dann fasst du jeden Block (Löschen dann Schreiben) immer nur einmal an. D.h. die bereits geschriebene Blöcke gehen auch bei Stromausfall nicht einfach verloren, sondern nur der aktuelle Block welcher z.B. noch im RAM liegt und noch nicht geschrieben wurde. Allerdings sind die Blöcke meist 512 Byte groß, und die verlierst du dann eben maximal. gruß cyblord
cyblord ---- schrieb: > Allerdings sind die Blöcke meist 512 Byte groß, > und die verlierst du dann eben maximal. Die Verwaltungseinheiten in der SD-Karte sind nicht bloss 512 Bytes gross. Flash-Medien, darunter auch SD-Karten, sind im Interface wie ein Eisberg. Der sichtbare Teil ist der kleinere.
FRAM geht nicht, da die SD-Karte im Falle eines Defektes in ein anderes Gerät eingesetzt werden soll. Was, wenn die 512 Byte genau die FAT betreffen? Dann ist mein Dateisystem hinüber???
fat schrieb: > Was, wenn die 512 Byte genau die FAT betreffen? > Dann ist mein Dateisystem hinüber??? Kann passieren. FAT wurde nicht für Ausfallsicherheit konstruiert. Modernere Filesysteme verwenden ein Transaction Logging, um grad laufende Operationen auf die Metadaten des Filesystems abzusichern. FAT nicht.
fat schrieb: > Kann das Dateisystem zerstört werden, wenn in einem ungünstigen > Zeitpunkt die Spannung ausfällt? Ja. > Und wenn ja, welche Operationen sind > hier kritisch? Jede Schreiboperation, insbesondere Schreiboperationen auf die FAT und auf Verzeichniseinträge. Dagegen hilft nur die Vermeidung von FAT, und die Nutzung eines Dateisystems mit "Journaling". Oder die Sicherstellung einer zuverlässigen Stromversorgung. > Was, wenn die 512 Byte genau die FAT betreffen? > Dann ist mein Dateisystem hinüber??? Selbst Microsoft als Erfinder von FAT scheint das als potentielles Problem erkannt zu haben -- und legt deswegen eine Kopie der FAT an, so daß mit geeignten Werkzeugen das Dateisystem zumindest eine gewisse Chance auf Reparatur hat.
http://www.mikrocontroller.net/articles/Speicher#EEPROM_Schreibzugriffe_minimieren Das Konzept kann man auch auf SD-Karten anwenden, die Zeiten liegen in der gleichen Größenordnung.
Rufus Τ. Firefly schrieb: > Selbst Microsoft als Erfinder von FAT scheint das als potentielles > Problem erkannt zu haben -- und legt deswegen eine Kopie der FAT an, Dummerweise liegt die Kopie direkt hinter dem Original. Folglich gibt es sehr wahrscheinlich einen Flash-Block, der mindestens Teile beider Kopien enthält.
Die Frage ist doch was überhaupt geschrieben wird. Wenn man gleich am Anfang einmal eine Datei mit der maximalen Größe anlegt. Dann kann beim schreiben in die Datei eigentlich nichts schiefgehen, weil die Verwaltungstrukturen nicht angepasst werden müssen.
Allerdings braucht man dann eigentlich auch kein Filesystem. :-)
A. K. schrieb: > Dummerweise liegt die direkt dahinter und damit je nach Grösse des > Mediums möglicherweise noch im gleichen Flash-Block. Naja, zur "Ehrenrettung" (nicht, daß da großartig was zu rettendes vorhanden wäre) sei angemerkt, daß FAT zu Zeiten entstand, als es noch keinerlei Flash-Speicher gab. Allerdings gibt es eine feste Verknüpfung von FAT als Dateisystem für Flash-Speicher; SD-Karten werden spezifikationskonform mit FAT16 bzw. SDHC-Karten mit FAT32 betrieben. Das setzt sich mit exFAT bei SDXC-Karten fort, wobei das die erste FAT-Variante ist, die auf die flash-spezifischen Belange Rücksicht nehmen könnte. Ob sie es tut, weiß ich allerdings nicht (habe noch keinen Blick in die Spezifikation geworfen). Dazu übrigens dies hier: http://www.heise.de/open/meldung/Samsung-veroeffentlicht-exFAT-Treiber-unter-GPL-1937325.html (Der Treiber ist GPL, aber der Gebrauch des Dateisystems muss von MS lizenziert werden?)
A. K. schrieb: > Allerdings braucht man dann eigentlich auch kein Filesystem. :-) Doch damit man die Karte z.B. per PC wieder auslesen kann.
cyblord ---- schrieb: >> Allerdings braucht man dann eigentlich auch kein Filesystem. :-) > > Doch damit man die Karte z.B. per PC wieder auslesen kann. Na und? Der PC kann Medien auch ohne Filesystem verarbeiten. Auch in Windows. Aber auch dann gibt es Metadaten. Jene unsichtbaren in der SD-Karte.
Wie Falk Brunner schon sagte, bestudiere dich mal dieses : http://elm-chan.org/fsw/ff/en/appnote.html#critical Da wird genau beschrieben wann es schief gehen kann. Dabei kannst du noch einen check einbauen ob alle kritische sachen gut sind abgehandelt vor dem letzten reset.
A. K. schrieb: > Na und? Der PC kann Medien auch ohne Filesystem verarbeiten. Auch in > Windows. aber nicht ohne Admin rechte.
Rufus Τ. Firefly schrieb: > Das setzt sich mit exFAT bei SDXC-Karten fort, wobei das die erste > FAT-Variante ist, die auf die flash-spezifischen Belange Rücksicht > nehmen könnte. Dann schon eher das: http://en.wikipedia.org/wiki/TexFAT
Peter II schrieb: > A. K. schrieb: >> Na und? Der PC kann Medien auch ohne Filesystem verarbeiten. Auch in >> Windows. > > aber nicht ohne Admin rechte. Und eben nicht Plug&Play. Also Karte reinstecken und Datei öffnen. > Aber auch dann gibt es Metadaten. Jene unsichtbaren in der SD-Karte. Richtig. Darum kann die Lösung eigentlich nur lauten: Stromversorgung so lange gewährleisten bis alles geschrieben wurde und die Karte und Controller schlafen gelegt sind. Alles andere wird wohl nicht sehr sicher funktionieren.
Peter II schrieb: > aber nicht ohne Admin rechte. Du kannst auch kein Filesystem ohne Admin-Rechte einhängen. Trotzdem geht's irgendwie. Der Trick ist, daß es Dienste gibt, die mit Admin-Rechten laufen und dann für normale Anwendungen einen eng begrenzten und genau definierten Subset der Möglichkeiten zur Verfügung stellen, die bei unbeschränktem Zugriff verfügbar wären. Nach exakt dem gleichen Schema kann man auch einen Dienst für den Zugriff auf Speicherkarten ohne Filesystem schreiben, dessen Dienstleistungen dann auch normale Nutzer in Anspruch nehmen dürfen. Das entscheidet der Dienst selber. Genauso lief das früher (als Winzigweich selber das noch nicht unterstützen mochte) auch mit der CD-Brennerei. Da brachte dann die Brennsoftware so einen Dienst mit.
> Kann das Dateisystem zerstört werden, wenn in einem ungünstigen > Zeitpunkt die Spannung ausfällt? Ja. Da du nicht sagst, wer schreibt (Windows wohl nicht) kann man postulieren, daß du möglichst optimalen code verwendest. Dann kann man eine neu geschriebene Datei (bzw. Änderungen an vorhadenen ) so abbilden, daß sie in leere Clurster geschrieben werden und in die FAT als belegt eingetragen werden (und erst hinterher, wenn die Daten auf der Platte stehen, die doppelt belegten wieder entfernt werden). Und wenn es eine Datei in einem Unterverzeichnis ist, kann man das ganze Verzeichnis kopieren und die Kopie in leere Cluster ablegen, so daß nichtmal das Ändern der Grösse und des Start- Clusters der Datei kritisch wäre. Auch die FAT wird kopiert, es gibt 2 Speicherplätze dafür, so daß eine heile bleibt wenn man mitten im Schreiben der anderen ausfällt. Nur den Eintrag ins Wurzelverzeichnis. den kann man leider nicht doppeln, da gibt es ein Problem, das Wurzelverzeichnis gibt es nur ein mal. Das ist der wesentliche Schwachpunkt am FAT Dateisystem warum es niemals transaktional werden kann und kompatibel bleibt.
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.