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.