Flash-Dateisysteme unter Linux
JFFS
[
Seminar Linux und Netzwerke, Softwareentwicklung mit Eclipse ] ... [
Inhaltsübersicht ] ... [
JFFS2 ]
JFFS
Das JFFS nennt sich zwar Journaling Flash File System, ist in Wirklichkeit aber ein reines Log-Dateisystem. Es werden Daten- und Metadatenblöcke wie oben beschrieben sequentiell gespeichert und einem Inode zugeordnet. Je nach Größe einer Datei werden mehrere Blöcke (struct jffs_raw_inode) einem Inode zugeordnet. Jeder dieser Blöcke beginnt mit der Inode-Nummer zu dem er gehört und allen Dateisystem-Metadaten, sowie einer variablen Menge an eigentlichen Daten. Zusätzlich wird in jedem Block eine Versionsnummer gespeichert, die immer höher ist als alle anderen Versionsnummern von Blöcken des aktuellen Inodes. Dieses s.g. version Feld ist ein unsigned 32-bit Wert, was dazu führt das maximal 4 Milliarden Blöcke pro Inode geschrieben werden können. Angesichts der limitierten Lebenszeit von Flashspeichern (siehe Einleitung) toleriert man diese Einschränkung jedoch. Die gleiche Methode wird für Inode Nummern angewendet. Werden Daten aktualisiert so werden die alten Daten mit einem deleted Flag versehen und somit als obsolet markiert.
Neben den normalen Metadaten wie uid, gid, mtime, atime, etc. wird hier auch der Name des Inodes zu dem der Block gehört und die Inode Nummer des Eltern Inodes gespeichert. Dieses Vorgehen wird in anderen Dateisystemen seit vielen Jahren vermieden, da es so nicht möglicht ist s.g. "Hardlinks" zu realisieren. Ein Hardlink bedeutet, dass zwei Dateinamen auf ein und die gleiche Datei zeigen. Dies ist in einigen Fällen sinnvoll. Zu diesem Zweck wurden in klassischen Dateisystemen neben Inodes die Dentries eingeführt, die eine Namen zu Inode-Nummer Zuordnung machen.
JFFS mounten
In JFFS wird zur Mountzeit das gesamte Speichermedium gescannt und jeder Block gelesen und interpretiert. So ist es möglich die gesamte Verzeichnisstruktur sowie eine Zuordnung jedes Inodes zu seiner physikalischen Lage zu konstruieren. Diese Daten werden zu jeder Zeit im Speicher gehalten und aktualisiert. So kann zum Beispiel eine Auflistung von Verzeichnisinhalten oder auch das Lesen einer Datei von der entsprechenden Stelle auf dem Medium sehr schnell geschehen.
Garbage Collection
Wie bereits angesprochen ist in einem Log Dateisystem irgendwann der Punkt erreicht, an dem man wieder am Kopf des Logs ankommt. Würde nun weiter sequentiell geschrieben werden, so würden mit großer Wahrscheinlichkeit irgendwann noch valide Daten überschrieben werden. Um dies zu verhindern ist eine Garbage Collection nötig.
Garbage Collection wird in JFFS entweder als Kernel Thread realisiert, der bereits ausgelöst wird wenn ein bestimmter Schwellwert an "dirty space" (obsoleten Daten) erreicht wird, oder aus dem Userspace, wenn z.B. eine Applikation feststellt, dass nicht mehr genug Speicher für einen Schreibvorgang zur Verfügung steht.
Der Garbage Collection Algorithmus versucht den ersten Erase Block auf dem Medium freizuräumen in dem er die einzelnen Datenblöcke auf das deleted Flag prüft. Ist der Block als obsolet markiert, so wird er übersprungen bis ein Block mit validen Daten oder das Ende des Erase Blocks erreicht wird. Stößt der Algorithmus auf einen Block mit noch validen (Meta)Daten, so wird dieser an das Ende des Logs kopiert und der alte Block (der nun eine niedrigere Versionsnummer trägt) als obsolet markiert. Dieses Umsortieren ist bereits leicht optimiert, in dem geschaut wird, ob man aus mehreren kleinen Blöcken etwas weniger dafür aber größere Blöcke erstellen kann.
Dieses Verfahren wird solange wiederholt bis der gesamte Erase Block mit obsoleten Daten gefüllt ist. Erst jetzt werden die Daten gelöscht und der Erase Block steht wieder zum Beschreiben zur Verfügung.
Probleme
JFFS war eines der ersten freien Flash-Dateisysteme und wurde zu Zeiten von Version 2.0 des Linux Kernels speziell für die -mit heute verglichen kleinen- Embedded Systeme von damals geschrieben. Es bringt einige Probleme mit sich:
- Garbage Collection
Das Problem bei diesem Ansatz der Garbage Collection ist, dass stets genug Platz für das Kopieren von einzelnen Blöcken vorhanden sein muss. Das Verhältnis von validen und obsoleten Daten muss also stets ausgewogen sein. Gerade bei kleinen Embedded Systemen ist es aber oft der Fall, dass wenig dynamische Daten anfallen. Des weiteren arbeitet die Garbage Collection dem eigentlich perfekten Wear Leveling entgegen. Man stelle sich ein 15MB Dateisystem vor, das z.B. 12MB statische Daten (wie Bibliotheken oder Binaries) und 3 MB dynamische Daten enthält (Log Dateien z.B.). Die Garbage Collection würde nun stets die 12MB statischen Daten verschieben, was eine unnötige Belastung der Flash Zellen darstellt, da diese Daten eben statisch sind.
- Kompression
Auf Grund der damals noch recht kleinen und teuren Flash Speichern war Kompression eine gefragte Sache. Leider konnte JFFS diese Option nicht bieten.
- Mountzeiten
Besonders in Embedded Systemen die von Endkunden oft nicht als Computer angesehen werden ist ein schnelles starten des Systems sehr wichtig. Durch die Vorgänge beim Mounten des JFFS ist dieser Vorgang allerdings sehr langsam. Für kleine Dateisysteme waren die Zeiten noch akzeptabel, aber heutige Flash Speicher lassen sich nicht in tolerierbaren Zeiten mounten.
- Hardlinks
Weniger essentiell, aber dennoch von Benutzern des Dateisystems gewünscht war die Möglichkeit Hardlinks zu erstellen. Diese ist in JFFS auf Grund der oben genannten Einschränkungen nicht gegeben.
[
Seminar Linux und Netzwerke, Softwareentwicklung mit Eclipse ] ... [
Inhaltsübersicht ] ... [
JFFS2 ]