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.
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.
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?)
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.
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.
