Linux unterstützt eine Vielzahl von Filesystemen, welche nach nonjournaling und journaling Filesystemen aufgeteilt werden können. Erstere haben einen entscheidenden Nachteil: Bei einem unvorhergesehenen Crash des Betriebssystems, z.B. durch Stromausfall, müssen diese beim Neustart jede einzelne Datei auf Koinsistenz untersuchen. Dies dauert auch auf schnellen RAID - Systemen mit einem parallelisierten fsck (FileSystemChecK) oft viele Stunden, bis er Server wieder im normalen Betrieb läuft. Hierbei werden alle defekten Dateien, in welche zum Zeitpunkt des Absturzes gerade hineingeschrieben wurde, in das Verzeichnis /lost+found/ gelegt. Wenn z.B. ein Datenbankserver gerade dabei war, in eine Datei zu schreiben, als der Server abstürzte, so muß man schon viel Glück haben, wenn die Datenbank nicht zerschossen ist, bzw. wieder repariert werden kann. Dies und Abschnitt 7.26 sind der Grund, warum Datenbanken grundsätzlich in sog. RAW Devices abgelegt werden, siehe Abschnitt 7.20. Mangels unausgereifter Technik, siehe Abschnitt 7.10, Abschnitt 7.27, Abschnitt 7.24, Abschnitt 7.28 hatten Kernel Versionen 2.0/2.2/2.4 öfter einmal hänger - alle Prozesse stoppten, weil der Kernel gerade mit einem hoch priorisierten Task beschäftigt war. Diese Defizite vielen unter Linux lange nicht so auf, weil Linux alle Schreib-und Lesezugriffe puffert (buffering), und ca. alle 10 Sekunden durch einen sync (genauer fsync) Kommando auf die Festplatte schreibt, mehr hierzu Abschnitt 7.26.
Journaling Filesysteme vermerken in einem Journal, einer versteckten Datein auf dem Filesystem (bei ext3 ist es /.journal), welche Dateien gerade im Gebrauch sind, damit nach dem Absturz #fsck.ext3 nur wenige Dateien auf Inkoinsistenz prüfen muß, was recht schnell geht. Leider ist der Check für Quotas (Speicherplatz - Limit für User, Gruppen) dann oft nicht "journaled".
Für Journaling Filesysteme gilt eigentlich dasselbe, wie für Datenbank-Server, sie müssen ACID (Atomicity Consistency Isolation Durability) beherrschen. Nach einem Crash muß das Datenbank - File wieder in denselben koinsistenten Zustand zurückversetzt werden können, den des vor dem letzten Schreibversuch hatte, eine Art "rollback". Hierzu muß das Filesystem vor dem Schreiben in die Datei eine Kopie des Teils des Datenbankfiles anlegen, der überschrieben werden soll, was natürlich auf die Performance drückt. Gibt es einen Crash, so kann fsck die Datei wieder in den Zustand versetzen, den die Datei vor der letzten Transaktion hatte. Alle Filesysteme, die nicht mindestens diesen Kriterien entsprechen, sollte man unter Linux nicht verwenden. Weitere Kriterien, die bei einem Filesystem wichtig sind, sind Volume Manager (LVM2, EVMS), Hot Relocation, Quotas, Disk Reservation, Spares, Mirroring, DMP (Multi Pathing), Dirty Region Logging, RAID, Writeahed Logging)
Linux unterstützt eine Auswahl von Journaling Filesystems, wie vor allem ext3, XFS, JFS, ReiserFS
| Zurück | Inhaltsangabe | Weiter |
| SMP, IRQs, Spin Locks, APICS | Nach oben | RAW - Devices |