248
4 Systemsoftware
liegen in einer ähnlichen Größenordnung. Selbstverständlich treten bei Einprozessorsystemen und Systemen, bei denen eine Task an einen Prozessorkern gebunden
wurde, keine verpassten Deadlines auf.
4.4.3 Dateisysteme für Flash-Speicher
Die Anforderungen eingebetteter Systeme an permanenten Speicher unterscheiden
sich von denen im Server- und Desktop-Bereich. Oft existiert eine große Menge an
statischen (nur-lese) Daten, wogegen die Menge an variablen Daten in vielen Fällen
sehr gering ist.
Dateisysteme können sich diese besonderen Bedingungen zu Nutze machen. Da
ein Großteil der nur-lese-Daten in aktuellen eingebetteten Systemen als Flash-ROM
realisiert ist, ist die Optimierung für diese Art von Speicher ein wichtiger Aspekt
bei der Nutzung von Linux in eingebetteten Systemen. Daher wurden eine Reihe
verschiedener Dateisysteme entwickelt, die speziell für die Nutzung von NANDFlash basierten Speichern ausgelegt sind.
Eines der stabilsten Flash-spezifischen Dateisysteme ist das protokollbasierte
Journaling Flash File System version 2 (JFFS2) [596]. JFFS2 protokolliert Änderungen an Dateien und Verzeichnissen im Flash-Speicher in Knoten (nodes). Es gibt
zwei Arten von Knoten. Inodes (dargestellt in Abb. 4.16) bestehen aus einem Header
mit Datei-Metadaten, gefolgt von optionalen Dateiinhalten, wogegen dirent-Knoten
Verzeichniseinträge darstellen, die jeweils einen Namen und die Nummer einer inode beinhalten. Knoten werden bei ihrer Erzeugung als gültig markiert und verlieren
ihre Gültigkeit, wenn eine neuere Version an einer anderen Stelle im Flash-Speicher
erzeugt wurde. JFFS2 unterstützt die transparente Kompression von Daten durch die
Speicherung komprimierter Daten als Nutzdaten der inodes.
Bitmaske
Knotentyp
0x1985
Gesamte
Knotenlänge
Knotenheader
CRC
Inode/Verzeichniseintrag
Gemeinsamer Header für Knoten
Knotenspezifischer Inhalt
Abb. 4.16 Inhalt einer JFFS2-Inode
Verglichen mit anderen protokollbasierten Dateisystemen wie Berkeley lfs [473]
existiert in JFFS2 allerdings kein zirkuläres Protokoll. Stattdessen verwendet JFFS2
Blöcke, die der Größe der löschbaren Segmente des unterliegenden Flash-Speichers
entsprechen. Wie in Abb. 4.17 gezeigt, werden Blöcke einzeln vom Start des Blocks
ab mit Knoten gefüllt.
Bereinigte (clean) Blöcke enthalten ausschließlich gültige Knoten, wogegen unbereinigte (dirty) Blöcke mindestens einen ungültigen (veralteten) Block beinhalten.
Um Speicher freizugeben, sammelt ein Dienst zur automatischen Speicherbereini-
4 Systemsoftware
liegen in einer ähnlichen Größenordnung. Selbstverständlich treten bei Einprozessorsystemen und Systemen, bei denen eine Task an einen Prozessorkern gebunden
wurde, keine verpassten Deadlines auf.
4.4.3 Dateisysteme für Flash-Speicher
Die Anforderungen eingebetteter Systeme an permanenten Speicher unterscheiden
sich von denen im Server- und Desktop-Bereich. Oft existiert eine große Menge an
statischen (nur-lese) Daten, wogegen die Menge an variablen Daten in vielen Fällen
sehr gering ist.
Dateisysteme können sich diese besonderen Bedingungen zu Nutze machen. Da
ein Großteil der nur-lese-Daten in aktuellen eingebetteten Systemen als Flash-ROM
realisiert ist, ist die Optimierung für diese Art von Speicher ein wichtiger Aspekt
bei der Nutzung von Linux in eingebetteten Systemen. Daher wurden eine Reihe
verschiedener Dateisysteme entwickelt, die speziell für die Nutzung von NANDFlash basierten Speichern ausgelegt sind.
Eines der stabilsten Flash-spezifischen Dateisysteme ist das protokollbasierte
Journaling Flash File System version 2 (JFFS2) [596]. JFFS2 protokolliert Änderungen an Dateien und Verzeichnissen im Flash-Speicher in Knoten (nodes). Es gibt
zwei Arten von Knoten. Inodes (dargestellt in Abb. 4.16) bestehen aus einem Header
mit Datei-Metadaten, gefolgt von optionalen Dateiinhalten, wogegen dirent-Knoten
Verzeichniseinträge darstellen, die jeweils einen Namen und die Nummer einer inode beinhalten. Knoten werden bei ihrer Erzeugung als gültig markiert und verlieren
ihre Gültigkeit, wenn eine neuere Version an einer anderen Stelle im Flash-Speicher
erzeugt wurde. JFFS2 unterstützt die transparente Kompression von Daten durch die
Speicherung komprimierter Daten als Nutzdaten der inodes.
Bitmaske
Knotentyp
0x1985
Gesamte
Knotenlänge
Knotenheader
CRC
Inode/Verzeichniseintrag
Gemeinsamer Header für Knoten
Knotenspezifischer Inhalt
Abb. 4.16 Inhalt einer JFFS2-Inode
Verglichen mit anderen protokollbasierten Dateisystemen wie Berkeley lfs [473]
existiert in JFFS2 allerdings kein zirkuläres Protokoll. Stattdessen verwendet JFFS2
Blöcke, die der Größe der löschbaren Segmente des unterliegenden Flash-Speichers
entsprechen. Wie in Abb. 4.17 gezeigt, werden Blöcke einzeln vom Start des Blocks
ab mit Knoten gefüllt.
Bereinigte (clean) Blöcke enthalten ausschließlich gültige Knoten, wogegen unbereinigte (dirty) Blöcke mindestens einen ungültigen (veralteten) Block beinhalten.
Um Speicher freizugeben, sammelt ein Dienst zur automatischen Speicherbereini-