4.4 Linux für eingebettete Systeme
249
Version
Inode-Nummer
001
Nummer der
Eltern-Inode
Name
In den Flash-Speicher geschriebene Knoten
Verzeichniseintrag-Knoten
inode-Knoten
Version
Offset
001
Länge
Daten
0x10
0x0
Filename.txt
aaaaa...
0x200
0x00
Öffne Datei und
schreibe 512 Bytes
'aaaaa...' an Offset 0
Benutzeraktionen
inode-Knoten
Version
Offset
002
Länge
Daten
bbbbb...
0x1000
0x200
inode-Knoten
Version
Offset
003
Länge
Daten
bbbbb...
0x800
0x1200
inode-Knoten
Version
Offset
004
Length
Data
ccccc...
0x400
0x100
Schreibe 6 kB
'bbbbb...' an
Offset 512
Schreibe 1 kB
'ccccc...' an
Offset 256
Abb. 4.17 Änderung des Flash-Inhalts bei Schreibvorgängen in JFFS2
gung (engl. garbage collector) die unbereinigten Blöcke im Hintergrund ein und gibt
diese wieder frei. Gültige Knoten aus unbereinigten Blöcken werden dabei in neue
Blöcke kopiert und ungültige übersprungen. Nach dem Ende des Kopiervorgangs
wird der unbereinigte Block als freigegeben markiert. Der garbage collector kann
auch bereinigte Blöcke nutzen, um die Abnutzung des Flash-Speichers gleichmäßig
zu gestalten (engl. wear-leveling). Damit wird vermieden, dass Blöcke wiederholt in
einem beschränkten kleinen Bereich eines größtenteils statischen Dateisystems, wie
es oft in eingebetteten Systemen der Fall ist, gelöscht werden.
4.4.4 Verringerung des Hauptspeicherbedarfs
Traditionell sehen Unix-ähnliche Systeme den Hauptspeicher (RAM) als einen Cache
für Sekundärspeicher auf einer Festplatte, d.h. Auslagerungsspeicher (engl. swap
space), an [386]. Dies ist eine sinnvolle Annahme für Server- und Desktop-Systeme
mit großen Festplatten und entsprechend großem Speicherbedarf. Bei eingebetteten
Systemen führt dies jedoch zu einer Verschwendung von Ressourcen, da Programme,
die im nichtflüchtigen Speicher eines Systems abgelegt sind, vor ihrer Ausführung
zunächst in den flüchtigen Hauptspeicher kopiert werden müssen. Dies trifft auch
auf den üblicherweise recht großen Betriebssystemkern selbst zu.
249
Version
Inode-Nummer
001
Nummer der
Eltern-Inode
Name
In den Flash-Speicher geschriebene Knoten
Verzeichniseintrag-Knoten
inode-Knoten
Version
Offset
001
Länge
Daten
0x10
0x0
Filename.txt
aaaaa...
0x200
0x00
Öffne Datei und
schreibe 512 Bytes
'aaaaa...' an Offset 0
Benutzeraktionen
inode-Knoten
Version
Offset
002
Länge
Daten
bbbbb...
0x1000
0x200
inode-Knoten
Version
Offset
003
Länge
Daten
bbbbb...
0x800
0x1200
inode-Knoten
Version
Offset
004
Length
Data
ccccc...
0x400
0x100
Schreibe 6 kB
'bbbbb...' an
Offset 512
Schreibe 1 kB
'ccccc...' an
Offset 256
Abb. 4.17 Änderung des Flash-Inhalts bei Schreibvorgängen in JFFS2
gung (engl. garbage collector) die unbereinigten Blöcke im Hintergrund ein und gibt
diese wieder frei. Gültige Knoten aus unbereinigten Blöcken werden dabei in neue
Blöcke kopiert und ungültige übersprungen. Nach dem Ende des Kopiervorgangs
wird der unbereinigte Block als freigegeben markiert. Der garbage collector kann
auch bereinigte Blöcke nutzen, um die Abnutzung des Flash-Speichers gleichmäßig
zu gestalten (engl. wear-leveling). Damit wird vermieden, dass Blöcke wiederholt in
einem beschränkten kleinen Bereich eines größtenteils statischen Dateisystems, wie
es oft in eingebetteten Systemen der Fall ist, gelöscht werden.
4.4.4 Verringerung des Hauptspeicherbedarfs
Traditionell sehen Unix-ähnliche Systeme den Hauptspeicher (RAM) als einen Cache
für Sekundärspeicher auf einer Festplatte, d.h. Auslagerungsspeicher (engl. swap
space), an [386]. Dies ist eine sinnvolle Annahme für Server- und Desktop-Systeme
mit großen Festplatten und entsprechend großem Speicherbedarf. Bei eingebetteten
Systemen führt dies jedoch zu einer Verschwendung von Ressourcen, da Programme,
die im nichtflüchtigen Speicher eines Systems abgelegt sind, vor ihrer Ausführung
zunächst in den flüchtigen Hauptspeicher kopiert werden müssen. Dies trifft auch
auf den üblicherweise recht großen Betriebssystemkern selbst zu.
