Flash-Dateisysteme unter Linux

JFFS2

[ Seminar Linux und Netzwerke, Softwareentwicklung mit Eclipse ] ... [ Inhaltsübersicht ] ... [ LogFS ]

JFFS2

Im Jahre 2001 wurde auf Grund großer Nachfrage beschlossen JFFS2 von Grund auf neu zu schreiben. Dabei wurden einige entscheidene Änderungen vorgenommen und es entstand JFFS2. Eine der Neuerungen war, dass es fortan nicht nur einen Typ von Blöcken gab, sondern mehrere. Dies führte letztlich dazu, dass JFFS2 nun auch POSIX kompatibel wurde.

Neue Block Typen

JFFS2_NODETYPE_INODE ist den alten Inodes in JFFS sehr ähnlich, allerings mit dem entscheidenen Unterschied, dass der Dateiname hier nicht mehr gespeichert wird. Wie anderen Dateisystemen üblich werden Namen und Inodes von nun an getrennt behandelt.
Hinzu kommt, dass nun Daten die mit diesem Typ Inode verknüpft sind mit einem von mehreren verfügbaren Verfahren komprimiert werden können. Eines der Verfahren ist die bekannte zlib Bibliothek.

JFFS2_NODETYPE_DIRENT übernimmt die Aufgabe Dateinamen Inodes zuzuordnen. In anderen Dateisystemen wird dies auch Dentry genannt.

JFFS2_NODETYPE_CLEANMARKER wird in komplett gelöschte Erase Blocks geschrieben um anzuzeigen, dass die Garbage Collection hier vollständig durchgeführt wurde und der Block zur freien Verfügung steht.

Neues Log Layout

Neben den Neuerungen bei den Blocktypen wurde auch die grundlegende Architektur an die wachsenden Bedürfnisse angepasst. In JFFS erstreckte sich das Log über das gesamte Speichermedium was zu Problemen bei der Garbage Collection führte. Zudem war es erlaubt, dass Blöcke über die Grenzen eines Erase Blocks hinaus existierten. In JFFS2 wird nun jeder Erase Block für sich als Log behandelt und Dateisystem Blöcke dürfen nicht mehr über die Grenzen eines Erase Blocks hinaus existieren. Auf diese Weise kann der Garbage Collection Algorithmus optimiert werden in dem geschaut wird, aus welchem Erase Block es sich gerade lohnt valide Daten zu sammeln und so Platz zu schaffen. Dies wird dadurch unterstützt, dass in zwei Listen -der clean_list und der dirty_list- gespeichert wird welche Erase Blöcke gerade frei oder zumindest noch teilweise belegt sind.
Ein einfacher Wahrscheinlichkeitsansatz ist dabei, den systeminternen interrupt timer (jiffies counter) zu benutzen und wenn dessen Wert Modulo 100 einen Wert ungleich 0 ergibt einen Block aus der dirty_list zu nehmen. Im Falle eines Ergebnisses von 0 wird entsprechend ein Block aus der clean_list gewählt.

**Abbildung 7:** Garbage Collection und Block Management in JFFS2
*Quelle: IBM*

JFFS2 mounten

Der Mountvorgang in JFFS2 ist im Vergleich zu seinem Vorgänger deutlich komplexer geworden und findet in vier Phasen statt, die jeweils einen kompletten Scan des Mediums benötigen.

Garbage Collection

Eine der Anforderungen an JFFS2 die bis heute im Raum stehen ist ein Beweis, dass die Garbage Collection Dead Lock frei arbeitet. Dieser ist bis heute nicht erbracht.
Das Problem liegt in der der Kompression die JFFS2 in Datenblöcken anwenden kann. Man stelle sich einen Datenblock vor der extrem gut komprimierbar ist. Nun sei es so, dass durch das Ändern eines Bytes in diesem Datenblock der gesamte Block gar nicht mehr zu komprimieren sei. Würde der alte Block nun durch die Garbage Collection verschoben werden so könnte es sein, dass der neue Block wesentlich größer ist als der alte. Daher kann keine Aussage darüber getroffen werden, wie viel Platz genau für eine Garbage Collection nötig ist.

Weiterhin Probleme

JFFS2 hat zwar einige Probleme behoben und ist deutlich nutzbarer als JFFS, aber einige elementare Probleme bestehen weiterhin:

Die Mountzeiten sind noch immer viel zu lang. Ein 1GB USB Stick hat in einem Test des LogFS Entwicklers Jörn Engel etwa 15 Minuten gedauert bis er gemountet war. Für einen Endnutzer ist solch eine Zeit inakzeptabel.

Es ist nicht bewiesen, dass die Garbage Collection Dead Lock frei arbeitet. Für Systemadministratoren von "kritischen" Systemen (man denke an Embedded Systeme in Krankenhäusern) ist dies eine nicht tolerierbare Tatsache.

Auch in JFFS2 kann das Problem der s.g. read und write disturbs nicht gelöst werden. Es kommt in Flashstrukturen hin und wieder vor, dass beim Lesen oder Schreiben einer Zelle benachbarte Bits ebenfalls "kippen", also ihren Wert ändern. JFFS2 hat zu diesem Zweck zwar bereits eine Checksumme in den Blockheadern vorgesehen, aber dies scheint noch nicht genügend zu sein.

Nach oben

[ Seminar Linux und Netzwerke, Softwareentwicklung mit Eclipse ] ... [ Inhaltsübersicht ] ... [ LogFS ]