Flash-Dateisysteme unter Linux
Flash-Dateisysteme
[
Seminar Linux und Netzwerke, Softwareentwicklung mit Eclipse ] ... [
Inhaltsübersicht ] ... [
JFFS ]
Entwicklung von Flash-Dateisystemen
Bei der Enwicklung von Flash-Dateisystemen wurden bereits vorhandene Konzepte aufgefriffen und an die Bedürfnisse von Flash Speichern angepasst.
In der Linuxwelt existieren schon länger sogenannte Journaling-Dateisysteme, die gegenüber klassischen Dateisystemen eine erhöhte Zuverlässigkeit haben und den Vorteil mit sich bringen, dass ein Dateisystemcheck nach z.B. einem Stromausfall deutlich kürzer ausfällt. Dies ist gerade für Systemadministratoren sehr wichtig, die möglichst hohe "Uptimes" einhalten müssen.
In einem Journaling-Dateisystem werden alle Änderungen die auf dem Speichermedium vorgenommen werden sollen zunächst als s.g. "Transactions" in ein Journal geschrieben. Im Falle eines Dateisystemcheks kann dann einfach nachvollzogen werden, welche Transaktionen bereits abgeschlossen wurden und welche nicht beendet werden konnten. Dies beschleunigt den Vorgang enorm.
Eine komplett andere Entwicklung machten 1991 Mendel Rosenblum und John K. Ousterhout unter der Annahme, dass in Zukunft in grossem Maße mehr Arbeitsspeicher zur Verfügung stehen würde und daher entsprechend viel Daten gecached werden können. Sie folgerten, dass das Suchen auf Festplatten (besonders bei Festplatten auf Grund der mechanischen Struktur ein Flaschenhals) sehr viel schneller ablaufen würde und man sich daher darauf konzentrieren müsse ein Dateisystem zu entwickeln, das das Schreiben auf ein Medium möglichst schnell macht.
Die Lösung war das von ihnen geschriebene Log-strukturierte Dateisystem SpriteFS. Das neue daran war, dass in SpriteFS immer nur ans Ende eines zirkulären Logs geschrieben wird. Das Log ist dabei so auf dem Datenträger angelegt, dass auch physikalisch stets sequentiell in den direkt folgenden Speicherblock geschrieben wird. Kam man wieder am Anfang des Logs an, so wurden vorhandene Daten überschrieben. Dieses Problem wurde durch eine Garbage Collection gelöst, die alte Daten sammelt und wieder ans Ende des Logs schreibt.
Was die beiden Wissenschaftler übersahen, war die Tatsache, dass nicht nur Arbeitsspeicher, sondern auch die Festplatten immer größer wurden. Log-basierte Dateisysteme waren daher nicht sehr performant und brachten lange Wartezeiten bei Dateisystemchecks mit sich. Dennoch sollten sie eine Renaissance in Flash-Dateisystemen erleben.
Wendet man das Prinzip der Log-basierten Dateisysteme nämlich auf Flash-Speicher an, so hat man bereits eine einfache, aber effektive Wear Leveling Strategie. Dadurch, dass auf dem Medium tatsächlich sequentiell geschrieben wird, werden auf den ersten Blick im Mittel alle Zellen gleich häufig geschrieben. In der Praxis stimmt dies leider nicht ganz, da auch speziell angepasste Dateisysteme, wie die weiter unten aufgeführten, bestimmte Daten wie den Superblock oder ein Journal an fixe Stellen des Mediums schreiben müssen, um diesen nach einem Systemstart finden zu können.
Neben Anpassungen für das Wear Leveling muss natürlich auch die Garbage Collection weiter an die Bedürfnisse von Flash Speicher angepasst werden.
Beispiele für Flash-Dateisysteme
Es gibt eine Vielzahl kommerzieller Flash-Dateisysteme wie zum Beispiel TargetFFS, smxFFS, EFFS oder auch das 1990 von Microsoft entwickelte FFS2. Speziell das FFS2 sollte sich als Standard durchsetzen, war aber so wenig performant, dass es 1998 von Intel als obsolet bezeichnet wurde und heute keine Bedeutung mehr hat. Oft werden solche kommerziellen Dateisysteme für Embedded Systems geschrieben. So zum Beispiel das Trimble File System, das für mobile GPS Geräte der Firma Trimble geschrieben wurde. Folgend sollen einige freie Dateisysteme vorgestellt werden.
[
Seminar Linux und Netzwerke, Softwareentwicklung mit Eclipse ] ... [
Inhaltsübersicht ] ... [
JFFS ]