Persistenten Speicher "sicher" (konsistent) beschreiben?

[Rainer K. (Gast)]

Hallo zusammen,

ich hätte mal eine Frage. Undzwar möchte ich Daten in einen persistenten 
Speicher schreiben, und diese sollen konsistent sein, auch bei einem 
Power loss im ungünstigsten Fall. Hierzu könnte ich ein FRAM oder EEPROM 
(o.ä.) verwenden.

Ich finde nirgendwo etwas zu Techniken / Methoden um die daten 
konsistenz / integrität zu sichern.

Kleines Beispiel:
Ich habe einen Wert der zyklisch auf einem EEPROM gespeichert wird, es 
ist wichtig dass nach einem System neustart der Wert noch vorhanden ist, 
er darf aber nicht verfälscht sein! Wenn ich den Wert schreibe kann ich 
ihn selbstverständlich danach verifizieren und ihn ggf. neuschreiben. 
Denkbar ist auch das Bilden einer Prüfsumme über den Wert um 
festzustellen ob es sich noch um den Wert handelt, der geschrieben 
wurde.

Was ist nun aber wenn beim Schreibzugriff die Spannungsversorgung 
einbricht. Der alte Wert wurde bereits zerstört und der neue noch nicht 
vollständig geschrieben. --> inkonsistenter Zustand.

Wie vermeide ich sowas? Den Wert doppelt speichern? Aber wenn einer von 
beiden verfälscht ist, welches ist der richtige?

Den Wert 3x speichern, und dann über einen Mehrheitsentscheid den 
richtigen finden?

Es muss doch einen guten Ansatz bzw. eine Methode geben die sich als 
"State-of-the-art" ethabliert hat.


Ich bin für Ideen, Links, Literatur Tipps dankbar.


Gruß, Rainer

[Bernhard R. (barnyhh)]

1. Schreiben der Daten in einem atomaren Zugriff;
2. Brown-Out-Detektor, der ausschließlich zwischen den Schreibzugriffen 
das System anhält;
3. Sicherheitsabstand zwischen Ansprechen des BO-Detektors und 
Nicht-Mehr-Schreiben können ausreichend, so daß Schreibzugriff sauber zu 
Ende durchgeführt wird, wenn BO-Triggerung anspricht.

Bernhard

[Markus J. (markusj)]

Wie wäre es mit einer Log-Struktur?
Drei miteinander verkettete Einträge, die entweder gültig oder ungültig 
sein können. Wird ein neuer Eintrag geschrieben, werden zuerst die Daten 
geschrieben und validiert, dann der Eintrag auf gültig gesetzt und erst 
danach wird der Vorherige als ungültig markiert.
Wenn du immer in einer bestimmten Reihenfolge schreibst, bekommst du so 
im Worst-Case maximal zwei Einträge die von sich behaupten, gültig zu 
sein - Beim ersten Eintrag stimmt das nicht, da hier lediglich nicht auf 
ungültig gesetzt wurde (nachholen!), der zweite Eintrag ist der 
aktuellere und damit gültig.

mfG
Markus

[Ingo W. (Gast)]

Ich würde, unabhängig vom BrownOut-Detektor, vor dem Schreibvorgang die 
Betriebsspannung prüfen (ADU), die mit einem großen Kondensator, der 
über den Schreibvorgang hält abgestützt ist.
mfG ingo

[Sam .. (sam1994)]

Du kannst ja zur sicherheit vor dem Speichern eine Variable im eeprom 
setzen, dass geschrieben wird und erst nach erfolgreichem schreiben sie 
löschen. So weißt du wenigsten ob das ergebnis stimmt oder nicht. Wenn 
du dazu noch z.b. 2 Werte speicherst kannst du mithilfe einer Prüfsumme 
feststellen welcher stimmt. Sollte die Prüfsumme verhauen sein, wird 
keiner der Werte stimmen. Oder: du speicherst in der Variable nicht ob 
der SChreibvorgang fertig ist oder nicht, sondern wie weit deine Daten 
geschrieben worden sind. Du speicherst deine Daten 3 mal und anhand der 
Variable siehst du welche noch nicht beschädigt sind. Z.b. Die Var ist 
2:
d.h. Die ersten beiden wurden geschrieben und im 3. Schreibvorgang wurde 
abgegbrochen.

[Andreas K. (derandi)]

Hast nicht gut genug gesucht, das nächste mal mehr anstrengen. Setzen, 
4-.

http://de.wikipedia.org/wiki/Journaling-Dateisystem

[TManiac (Gast)]

Folgendes Verfahren wird zum Beispiel in Steuergeräten bei 
Kalibrierdaten (längere Tabellen) genutzt.

Weniger relavante Daten, werden ausschließlich durch CRC gesichert. Hier 
nimmt man es in Kauf, dass inkonsistente Daten einfach durch 
Default-Werte aus dem Flash ersetzt werden.

Wichtigere Daten werden durch eine Sicherheitskopie geschützt, welche 
auch eine CRC hat.
Geschrieben werden beide Tabellen nacheinander und die CRC jeweils am 
Ende einer Tabelle.
Gelesen wird erst die Haupttabelle und mit der CRC geprüft. Stimmt es 
nicht überein, wird die Backup-Tabelle geladen und mit ihrer CRC 
überprüft. Sollte die widererwarten auch defekt sein, werden immer noch 
FAIL-Safe-Default-Werte aus dem Flash genommen.
Da der Spannungseinbruch aber nur beim Schreiben einer Tabelle passieren 
kann (die zwei Tabellen werden ja unabhängig geschrieben), sollte bei 
einem neuen Hochfahren eine der beiden Tabellen i.O. sein, auch wenn sie 
evtl. noch veraltete Daten enthalten.

Gruß,
TManiac

[Rainer K. (Gast)]

Wow - vielen Dank für die wirklich zahlreichen Ansätze und Vorschläge!