Aus Linux-Magazin 11/2007

Neue Dateisysteme nehmen Rücksicht auf den begrenzten Lebenszyklus von Flashspeichern

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.

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.

Flash-Technik

Flash-EEPROMs sind Speicherbausteine mit nicht-flüchtigem Inhalt, sie behalten die Daten auch ohne Spannungsversorgung. Wegen der kleinen Chips und günstiger Herstellungskosten kommen meist NAND-Flashbausteine zur Auslieferung, bei denen immer eine bestimmte Anzahl Flashtransistoren (so genannte Floating Gates) in Serie geschaltet ist. Weil selektive Schreiboperationen immer nur vom logischen Zustand Falsch zum Zustand Wahr möglich sind, muss eine Logik vor jedem Schreibvorgang einen Löschzyklus einschieben.

Löschen nur en Block

Im Gegensatz zu gewöhnlichem EEPROM-Speicher lässt sich beim Flash-EEPROM ein Wort, die kleinste adressierbare Speichereinheit (8 bis 64 Bit), nicht einzeln löschen, sondern nur blockweise. Ein Block ist meist ein Viertel, Achtel, Sechzehntel und so weiter der Gesamtspeicherkapazität eines Chips. Diese EEPROM-Blöcke (auch Eraseblock genannt) sind deutlich größer als die Blöcke, mit denen herkömmliche Filesysteme arbeiten. Zudem ist die Anzahl der Löschzyklen (Endurance) begrenzt. Die Hersteller garantieren für jeden einzelnen Block nur 100 000 bis eine Million Zyklen.

Grund für die Abnutzung: In den Floating Gates durchtunneln bei jedem Löschzyklus die Elektronen die Oxidschicht des Transistors (Fowler-Nordheim-Tunneleffekt). Die für diesen quantenmechanischen Effekt erforderliche hohe Spannungen beschädigt bei jedem Löschvorgang ein wenig die Oxidschicht, die das Floating Gate umgibt (Abbildung 2). Ist die Degeneration so weit fortgeschritten, dass die im Transistor gefangene Elektronen entweichen, geht das dort gespeicherte Bit verloren und die Zelle ist defekt. Die Hersteller der Flashgeräte versuchen diesem schleichenden Effekt entgegenzuwirken, indem sie Reservezellen und ein Defektmanagement einbauen, das kaputte Blöcke wegmappt.

    Abbildung 2: Die Oxidschicht um das FloatingGate hindert die Elektronen daran, abzufließen. Durch die Löschvorgänge degeneriert jedes Mal die schützende Oxidschicht.    (Bild: Quelle: Wikipedia)

Abbildung 2: Die Oxidschicht um das FloatingGate hindert die Elektronen daran, abzufließen. Durch die Löschvorgänge degeneriert jedes Mal die schützende Oxidschicht. (Bild: Quelle: Wikipedia)

Vor- und Nachteile der NAND-Flashes

Pro:

  • Kurze Zugriffszeiten
  • Geringer Energieverbrauch
  • Datenerhalt auch ohne Stromversorgung
  • Resistent gegen Erschütterungen und magnetische
    Felder
  • Kleine Bauform, leicht, geräuschlos, hohe Datendichte

Kontra:

  • Schreibt langsamer als eine Festplatte
  • Nur sektorweise löschbar
  • Begrenzte Anzahl Schreibzyklen
  • Teurer als Festplatten und optische Medien

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]

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 2 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben