Seit Flashspeicher billige Massenware sind, muss sich Linux mit deren Eigenschaften auseinandersetzen – auch mit den nachteiligen. Ein neues Dateisystem verspricht eine Lösung.
Mit Flash-Speicherchips hatten Linux-Programmierer früher nur im Embedded-Bereich Kontakt. Bei solch dedizierter Hardware konnten sie ihre Applikationen so trimmen, dass sie nur selten in den Speicher schreiben und wenn, dann größere Blöcke am Stück. Außerdem vermieden sie es, mehrfach dieselbe Stelle zu überschreiben. Diese Strategien sind nötig, um den Besonderheiten dieses Memory-Typs gerecht zu werden (siehe Kasten “Flash-Technik”).
Seit einigen Jahren nun haben Flashspeicher in Form von USB-Sticks oder als Speicherkarten für Kameras, PDAs und Mobiltelefone, Solid State Drives sowie MP3-Player einen dramatischen Preisverfall erlitten und avancieren zur Massenware. Folge: Die normale Applikation weiß nicht, ob sie vielleicht mit einem Flashspeicher arbeitet, sie wünscht sich ein gewöhnliches Filesystem. Die Verantwortung wechselt in die Hardware oder in den Kernel und damit zu den Kernelentwicklern. In Cambridge wurde Flash zum Thema, Jörn Engel hielt einen Vortrag und nahm (aus Demonstrationsgründen die recht altmodischen) Smartmedia-Karten als Beispiel.
Seit etwa dem Jahr 2000 besitzt der Kernel den Flash Translation Layer, kurz FTL. Diese Schicht kümmert sich um alle Besonderheiten dieser Speicher und bietet nach oben hin ein Blockdevice an. Das erlaubt es dem Dateisystem, Sektoren zu lesen und zu schreiben, ohne zu wissen, wie der Speicher konkret organisiert ist, und ohne sich vor dem Schreiben ums Löschen zu kümmern. Zurzeit unterstützt der Linux-Kern fünf FTL-Varianten im Memory-Subsystem. Hinzu kommt, dass einige USB-Massenspeichertreiber eigene Zugriffsabstraktionen mitbringen.
Blockverwaltung
Da Filesystem-Blöcke viel kleiner sind als die Flash-Blöcke, optimiert der FTL Schreibzugriffe. Er fasst Änderungen zusammen, um Lösch- undSchreibzyklen zu sparen und damit die Lebensdauer des Chips und den Durchsatz zu verbessern. Dazu sind eigene Verwaltungsstrukturen nötig (Block Mapping), die zusammen mit Garbage-Collection-Techniken arbeiten. Diese Arbeit erledigt beispielsweise bei Compactflash-Karten (CF) und USB-Speichersticks bereits der Controller und liefert dem System eine gewöhnliche ATA-Schnittstelle.
Interessanter ist der Raw-Zugriff, etwa bei den oben genannten Smartmedia-Karten oder bei echten PCMCIA-Flashkarten. Zunächst muss Root eine FTL-Partition auf dem Gerät erzeugen. Dazu benutzt er das Flash Translation Layer Formatting Utility:
ftl_format -q -i -s Verschonter_Bereich -r Reservierter_Bereich -b Bootgröße Device
Zwingend ist davon nur die Angabe des Device. Der Aufruf »ftl_format -i /dev/mem0c0c« formatiert das Raw-Device im interaktiven Modus. Die Option »-r« reserviert am Anfang des Flashspeichers einen Bereich, der nicht Teil der FTL-Partition ist und sich dazu eignet, einen Bootblock oder eine herstellereigene Device-Verwaltung aufzunehmen. Einmal partitioniert lässt sich die Karte wie ein normales Blockgerät verwenden:
mke2fs /dev/ftl0 mount -t ext2 /dev/ftl0 /mnt
Filesysteme wie Ext 2 oder FAT sind nicht für den Betrieb auf Flashspeichern optimiert. Die FTL weiß nicht einmal, ob ein Block gelöscht ist oder Teile einer Datei enthält, weil das Filesystem diese Information nicht an die Blockschicht weitergibt. Die Arbeit der Garbage Collection ist dadurch reichlich erschwert.
Lückenfüller
In diese Lücke springen spezielle Systeme wie JFFS 2 (Journaling Flash File System 2 [1], eine Weiterentwicklung von [2]), UBIFS [3] oder YAFFS [4]. Der Name “Journaling Flash File System” ist unglücklich gewählt, da es Log-strukturiert arbeitet. Ein neuer Stern an diesem Teil des Linux-Himmels heißt Log-FS [5]. Achtung: Es besteht Verwechslungsgefahr mit dem (eingeschlafenen) Projekt Log Structured File System (LFS, [6]), entstanden in Googles “Summer of Code 2005”-Programm.
Jörn Engel, der Maintainer von Log-FS, positioniert seinen Code gegen JFFS 2 und will bei großen Partitionen gegen JFFS 2 punkten, das hier Probleme mit der Performance hat. So dauert das Mounten eines 1-GByte-USB-Sticks laut Engel 15 Minuten.
Wandernde Bäume
Das clevere Konzept in Log-FS ist seine baumartige Verwaltungsstruktur. Es löscht und schreibt geänderte Blöcke nicht an Ort und Stelle, sondern legt den Inhalt dieser Blöcke am Ende des benutzen Speicherbereichs ab. Dabei fasst es – ganz wie die Garbage-Collection-Methoden im FTD – Änderungen zusammen, die sich über Ausschnitte mehrerer Eraseblocks ziehen. Zudem muss es die Baumstruktur aktualisieren. Dazu schreibt Log-FS alle Äste vom geänderten Block bis zur Wurzel neu ans Ende des benutzten Flashspeichers und ernennt damit implizit die bisher genutzten Blöcke zu freiem Speicherplatz (Abbildung 1).

Abbildung 1: Log-FS schreibt Änderungen out of Place. In der Baumstruktur (a) legt es einen geänderten Block an einer neuen Stelle an (b) und lässt den alten Block unverändert. Die Änderung ist aber noch nicht verlinkt, daher muss Log-FS auch den Vaterknoten neu anlegen (c). Erst wenn es auch den Wurzelknoten erwischt hat (d), gilt die neue Struktur. Das Dateisystem bleibt damit immer in einem konsistenten Zustand.
Beim Mounten eines Log-FS-Device sucht der Treiber nach dem letzten Wurzelknoten. Von dem aus ist die Datenstruktur auf dem aktuellen Stand. Das Verfahren spart damit Lösch- und Schreibaktionen und es verteilt die verbliebenen Änderungen über das Device.
Log-FS in der Praxis
Um Log-FS zu benutzen, muss man die Vanilla-Kernelsourcen patchen. Die Log-FS-Site [5] hält Patches für Linux 2.6.18, 2.6.20 und 2.6.21 vorrätig. An derselben Stelle gibt es das Mklog-FS-Tool. Nach dem Konfigurieren, Übersetzen und Booten kann man ein Memory Technology Device (MTD, [7]) »mklogfs /dev/mtd0« anlegen und ins Dateisystems einhängen: »mount mtd0 /mnt -t logfs«.
Derzeit befindet sich Log-FS noch in der Entwicklung. Jörn Engel gibt auf [5] zum Beispiel an, dass sein Filesystem den Baum noch zu häufig aktualisiert und damit Performance verschenkt. Bleibt zu wünschen, dass seine Baumschule weiterhin so gut gedeiht.
|
Infos |
|---|
|
[1] JFFS 2: [http://sources.redhat.com/jffs2/] [2] JFFS: [http://developer.axis.com/old/software/jffs/index.html] [3] UBIFS: [http://www.linux-mtd.infradead.org/doc/ubifs.html] [4] YAFFS: [http://www.yaffs.net] [5] Log-FS: [http://www.logfs.org/logfs/] [6] LFS: [http://logfs.sourceforge.net] [7] MTD: [http://linux-mtd.infradead.org] |






