Leichter Circular Log-Algorithmus (dateisystemähnlich) für Flash-basierten Speicher

Ich arbeite derzeit an einem Projekt, bei dem eine ziemlich anwendungsspezifische Metrik über einen langen Zeitraum schnell und kontinuierlich protokolliert wird. Dazu habe ich einen NXP M0 und einen 32MiB SPI-Flash-Chip verwendet. Die Protokollierung ist kontinuierlich und muss viele Jahre im Feld (10+) dauern. Sie wird regelmäßig von einem Menschen auf Trenderkennung überprüft. Schließlich füllt sich der Puffer und beginnt, alte Daten zu überschreiben, was vollkommen in Ordnung ist. Ich habe einen einfachen Algorithmus entwickelt, mit dem das gesamte Flash-Gerät nach dem Einschalten nach dem aktuellen Kopf durchsucht werden kann (das Gerät wird außerhalb meiner Kontrolle ziemlich häufig ausgeschaltet), sodass die Protokollierung einfach dort fortgesetzt werden kann, wo sie aufgehört hat. Ich kann diesen Spaziergang nur mit brutaler Gewalt durchführen und dies mit ~ 4s als Worst-Case-Szenario tun.

Dies brachte mich zum Nachdenken, gibt es logarithmisch strukturierte Dateisysteme, die für Flash-Geräte und Mikrocontroller geeignet sind? JFFS und all die anderen bekannten log Structured FSs, die ich mir vorstelle, wären für einen einfachen Mikrocontroller etwas schwer (hängt natürlich von der Anwendung ab). Um genauer zu sein, würde ich gerne wissen, welche Algorithmen speziell als kreisförmiges Protokoll mit schneller Kopfsuchzeit konzipiert sind und / oder welche für ein "traditionelles" Dateisystem auf einem Flash-Gerät entwickelt wurden, das auf einem ausgeführt werden kann Mikrocontroller. Traditionell in diesem Sinne mit JFFS vergleichbar zu sein, wo es eine Datenstruktur gibt, die eine Sammlung veränderlicher Dateien mit wahlfreiem Zugriff in einem hierarchischen Namensraum darstellt.

Seil Datenstruktur

Ich bin fasziniert von der Seildatenstruktur. Ich habe ein Hobbyprojekt, das versucht, es an einen Mikrocontroller mit nur wenigen Bytes RAM anzupassen, der an einen riesigen Flash-Speicher angeschlossen ist, damit ich Text mit variabler Länge in riesige Textdateien einfügen und löschen und auf andere Weise willkürlich bearbeiten kann. Textdateien sind viel zu groß, um in den RAM zu passen. Das Löschen der letzten Hälfte der Datei und das erneute Schreiben in Flash, verschoben um ein Byte, jedes Mal, wenn ich ein Zeichen in der Mitte einer Multi-Megabyte-Textdatei einfüge oder lösche, wäre viel zu langsam, aber die Seildatenstruktur kann dies viel schneller tun. Da die Seildatenstruktur solche veränderlichen Dateien mit variabler Länge und wahlfreiem Zugriff als unveränderliche Teile fester Länge darstellen kann, scheint sie gut zum Flash-Speicher zu passen - alle Änderungen werden kreisförmig geschrieben. Leider sind in meinem Code noch nicht alle Fehler behoben. :-(

chronologische Protokolle fester Länge

Ich habe ein ähnliches Rundschreiben-System für ein Produkt zum Laufen gebracht, das ich mitentwickelt habe.

Ich habe einfach nacheinander Datensätze mit fester Länge geschrieben und Flash als kreisförmiges Array ausgefüllt.

(Mit einem völlig leeren Blitz begann ich, Datensätze ungefähr 3 Blöcke vor dem Ende des Arrays zu schreiben, damit ich den kreisförmigen Wrap-Around testen konnte, nachdem nur wenige Datensätze von Daten gespeichert wurden, anstatt bei Datensatz Null zu beginnen und auf a zu warten Daten im Wert von einem Monat, die geschrieben werden müssen, bevor festgestellt wird, dass mein Wrap-Around-Code einen Fehler enthält.

Ich habe dafür gesorgt, dass immer mindestens 2 gelöschte "Löschblöcke" zum Schreiben bereit waren. Wenn nach dem Schreiben eines Datensatzes nur 2 "gelöschte Blöcke" leer waren, habe ich den ältesten Datenblock bedingungslos gelöscht - den 3. Block der ältesten Daten nach den 2 "gelöschten Blöcken". (Gegen Ende des Flash-Speichers bedeutet "nach" "um den Anfang des Flash-Speichers wickeln".) Vielleicht wäre ein einzelner gelöschter Block ausreichend gewesen - ich vergesse, warum ich dachte, ich brauche mindestens 2 und manchmal 3) .

Ich habe genau vergessen, wie viele Datensätze ich in jeden "Löschblock" eingefügt habe, aber ich habe sichergestellt, dass ich nie einen Datensatz über zwei Löschblöcke hatte - die ersten 2 Bytes jedes Löschblocks waren entweder der "gelöschte" Wert 0xFFFF oder Die ersten zwei Bytes einer Fletcher-16-Prüfsumme (die niemals 0xFFFF ist) im Header jedes Datensatzes.

Das machte es schnell, beim nächsten Einschalten zu scannen und den Kopf des kreisförmigen Protokolls zu finden - ich musste nur die ersten zwei Bytes jedes Löschblocks betrachten, um zwischen "gelöschten" und "Daten" -Blöcken zu unterscheiden. (Ich war ein wenig besorgt über einen "Stromausfall während des Löschens eines Blocks", der dazu führte, dass die ersten beiden Bytes auf 0xFFFF gelöscht wurden, aber nicht gelöschte Bytes in der Mitte des Blocks zurückblieben. Deshalb schrieb ich Code, den der Mikrocontroller überprüfen sollte dafür und starten Sie den Prozess "Block löschen" neu).

Bitte sagen Sie mir, wenn Sie andere flashfreundliche Datenstrukturen oder Dateisysteme finden.

Es ist schon einige Jahre her, aber ich wollte dem nachgehen, falls jemand anders vorbeikommt. Es sieht so aus, als ob es heutzutage einige Projekte gibt, die aktiv gewartet werden (Stand: Januar 2020) und Dateisysteme für Mikrocontroller sind, die auf NOR SPI Flash ausgerichtet sind.

Beachten Sie, dass ich diese in keiner Weise getestet habe, aber sie genau das tun, wonach die ursprüngliche Frage gesucht hat: "... Datenstruktur, die eine Sammlung veränderlicher Dateien mit wahlfreiem Zugriff darstellt ..."

https://github.com/ARMmbed/littlefs - Erstellt von ARM, BSD-lizenziert

https://github.com/joembedded/JesFs - Scheint nicht wirklich lizenziert zu sein, wurde aber speziell für SPI NOR Flash entwickelt.