Filesysteme

Inhalt:

Filesysteme
ext3
JFS
- Nachteile
ReiserFS
- Nachteile
XFS
- Nachteile
Zusammenfassung
Fazit
Quellen, Weiterführende Literatur & Links

1. Filesysteme

Jede Anwendung besteht aus Daten, die meisten Anwendungen wollen selbst Daten ablegen, früher oder später wird es
nötig diese Daten abzulegen bzw. andere Daten einzulesen.
Hier kommt es darauf an Daten speicherplatzschonend zu verwalten und schnellen Zugriff darauf zu haben..
Filesysteme unter Linux besitzen eine baumartige Struktur. Hierbei gibt es zwischen den Linux-Distributionen Unterschiede.
Alle Linux Dateisysteme besitzen aber folgende gemeinsame Bestandteile:

•   Files (Dateien)
•   Directorys (Verzeichnisse)
•   Devices (Gerätedateien)
•   Unix domain sockets
•   named pipes
•   Links

1.1. Aufbau eines Standard-Dateisystems (UFS, ext2)

Beim ext2 Filesystem wird der vorhandene Plattenplatz in Blöcke gleicher Größe (z.B. 1024 Byte) aufgeteilt.
Diese Blöcke nummeriert man durch und fasst eine bestimmte Anzahl zu Blockgruppen zusammen.
Der erste Block jeder dieser Gruppen wird Superblock genannt und enthält Informationen zur Verwaltung des Dateisystems.

Es gibt folgende Blockgruppen:

-   Superblock (Label, Mount Count, Check Interval, Dateisystemstatus, Anzahl Inodes, Blöcke...)
-   Dateisystembeschreibung (Adressen der Block- und Inodes-Abbilder, Anzahl der freien Inodes und Blöcke, Anzahl der Verzeichnisse)
-   Block-Abbild (Bitmap der Block-Belegung)
-   Inodes-Abbild (Bitmap der Inodes-Belegung)
-   Inodes-Tabelle (Verzeichnis der Inodes)
-   Datenblöcke (die eigentliche Daten)

In dem Block-Abbild wird für jeden Datenblock ein Bit gespeichert.
Dieses Bit wird gesetzt oder gelöscht je nachdem, ob der Block belegt oder frei ist.
Das gleiche in der Inodes-Tabelle, auch hier gibt es ein Bit-Abbild.
Die letzte Gruppe dient als Speicherplatz für Daten. Hier und nur hier werden die
eigentlichen Daten gespeichert, die anderen fünf Gruppen sind lediglich der Verwaltungsüberbau.

Bei nahezu allen Unix-Dateisystemen - auch bei dem Linux-Klassiker ext2 - ist die zentrale Verwaltungseinheit der Inode. Zu jeder Datei gehört genau ein Inode, der alle Verwaltungsinformationen außer ihrem Namen enthält:

- Dateityp
- Besitzer
- Zugriffsrechte
- Größe
- Zugriffszeiten
- die von dieser Datei belegten Datenblöcke auf der Festplatte.

Die Verzeichnisse verknüpfen Dateinamen mit Inodes, die dann auf die
eigentlichen Datenblöcke verweisen.
Eine Datei besteht aus ihrem entsprechenden Inode und aus mehreren
Datenblöcken, die die eigentlichen Daten enthalten.
Die Verwaltungsinformationen im Inode und der eigentliche Dateninhalt
der Datei sind vollkommen getrennt und können auch unabhängig
voneinander bearbeitet werden.
Wer eine Datei in ein neues Verzeichnis verschiebt, ändert den Inode
und die entsprechenden Verzeichniseinträge, aber nie werden die Daten der Datei selbst geändert.

Damit das Dateisystem fehlerfrei arbeiten kann, müssen alle Metadaten konsistent sein:
Jeder Inode, auf den ein Verzeichniseintrag verweist, muss mit sinnvollen Inhalten gefüllt sein,
sonst weist der Dateiname ins Leere. Einer Datei zugeordnete Datenblöcke müssen in Block-Bitmap,
benutzte Inodes und in der Inode-Bitmap als belegt markiert sein.

1.2. Welche Filesysteme gibt es

Unter Linux gibt es eine ganze Reihe von Dateisystemen, hier eine kurze nicht vollständige Übersicht:

AFS ein verteiltes Dateisystem, meist WAN genutzt
autofs für das automatische Mounten eines Dateisystems bzw. Datenträgers ins Gesamtsystem - ist also kein echtes Dateisystem
devpts für Pseudoterminals (nach UNIX-98-Spezifikation)
ext2 der Standard unter Linux ext3 Weiterentwicklung von ext2, beherrscht Journaling
hpfs das OS/2-Dateisystem
iso9660 Standardformat für CD-ROMs und DVDs
JFS Von IBM entwickeltes Journaling Filesystem, ursprünglich für AIX (IBMs UNIX) entwickelt und seit Februar 2000 auch unter einer Open Source Lizenz für Linux verfügbar
minix Dateisystem von Minix, wird oft für Linux-Disketten gebraucht
msdos Dateisystem für MS-DOS-Partitionen und Disketten (kurze Dateinamen)
nfs Netzwerkdateisystem für UNIX, um Daten von anderen Rechnern zu lesen
ntfs Windows-NT/2000 Dateisystem (allerdings nur mit Lesezugriff von Linux aus)
nwfs kann ein NetWarediskfilesystem lesen
proc Prozessverwaltung unter /proc
ReiserFS Reiser-Dateisystem, beherrscht Journaling
smbfs Samba (Netzwerkdateisystem unter Windows)
swap Swap-Partitionen oder -Dateien
udf Universal Disk Format (CD-RWs und DVDs)
usbdevfs Einbinden und Verwalten von USB-Geräten
vfat DOS/Windows-9x-Dateisystem (lange Dateinamen)
XFS Journaling Filesystem unter UNIX. Ursprünglich von SGI für IRIX,
das hauseigene UNIX entwickelt, aber mittlerweile unter GPL für Linux verfügbar

1.3. Was sind Binärbäume

Anstatt wie beim ext2 (und ext3) Dateisystem die Daten als verkettete Liste zu speichern,
benutzt man hier Binärbäume.
Hat ein Verzeichnis z.B. 1000 Einträge, dann werden im Durchschnitt etwa 500 Suchschritte
zur Auffindung ein Datei benötigt, während beim (ausbalancierten) Binärbaum bereits nach
zehn Schritten (ld 1000) das Ergebnis zu Tage tritt.
Der Performance-Gewinn wird allerdings mit wesentlich komplexerem
(und damit fehleranfälligem) Programmcode erkauft.
Nach jedem neuen Eintrag muss der Binärbaum neu "ausbalanciert" werden, damit
alle Wege von der Wurzel bis zu den Entferntesten Blättern etwa gleich lang bleiben.
Viele Dateisysteme verwenden aber eine Art Mischform zwischen Listen und Bäumen.

2. ext3

Autor von ext3 ist Dr Stephen C. Tweedie der ext3 für den Kernel 2.2 geschrieben hat.
Es ist demnächst Release 1.0 zu erwarten und ext3 ist eines der stabilsten Dateisysteme.
Der größte Vorzug von ext3 ist aber seine Kompatibilität mit ext2, ext3 setzt auf ext2 auf und
erweitert ext2 um journaling Funktionalität.
Man kann ein ext2 Dateisystem einfach mittels tune2fs -j /dev/hdXX
konvertieren.
Ein neues ext3 Dateisystem erzeugt man mit: mke2fs -j /dev/hdXX
Das Journal bei ext3 ist eine normale Datei, wandelt man ein ext2 Dateisystem nach ext3
um, taucht diese Datei als /.journal im Verzeichnisbaum auf.
Man kann das ext3 Filesystem auch als ext2 mounten (ohne Journaling),
dies kann hilfreich sein wenn das System nicht mehr von der Plattet bootet
und man eine ältere Rettungsdiskette zur Hand hat,
außerdem lassen sich dann die ext2-Tools (z.B. e2fsck) nutzen.
ext3 benutzt wie ext2 Inode-Tabellen, Block- und Inode-Bitmaps und
linearen Verzeichnisstrukturen. Trotzdem ext3 auf Binärbäume
verzichtet ist die Leistung gut.

Die Mount-Option "data=writeback" anstatt der Standardeinstellung "data=ordered"
bringt ein bisschen mehr Tempo. (ext3 achtet jetzt nicht mehr darauf, dass ein
"Commit" von Blocknummern in Inodes erst erfolgt, wenn die zugehörigen
Daten auf die Platte geschrieben sind)
Allerdings besteht das Risiko, dass das Abspielen des Journals nach einem
Crash Dateien "wiederherstellt", in denen Daten aus zuvor gelöschten Dateien stehen
(ebenfalls ReiserFS und XFS).
Und mit der Mount-Option "data=journal" kann ext3 sogar Datenkonsistenz
garantieren, indem es Datenblöcke ins Log übernimmt und später auf die Platte überträgt.
Das bringt auch bei langsamen Platten mehr Geschwindigkeit, da die Daten aufeinander
folgend ins Log geschrieben und später erst endgültig quer über die Platte
an ihren Bestimmungsort übertragen werden.

2.1 Was ist Journaling

Hier interessiert hauptsächlich das Problem, dass falls das System nicht korrekt
heruntergefahren wurde (Stromausfall, Notebookakku alle, …)
die Daten auf der Platte inkonsistent sind
(z.B. Stromausfall beim Schreiben einer Datei).
Beim Mounten des Filesystems wird im Superblock ein Bit (Validbit) gelöscht,
das beim herunterfahren wieder gesetzt wird.
Fehlt dieses Bit beim nächsten Starten wird der Datenträger mittels e2fschk überprüft
und wenn nötig repariert (falls es möglich ist).
Die Reparatur ist aber nicht immer möglich, Daten die nicht repariert werden
können landen im /lost+found-Verzeichnis.
Da die gesamte Platte überprüft werden muss,
kann dieser Vorgang (Recovery) mehrere Minuten bis Stunden
(je nach bis Plattengröße und Geschwindigkeit) in Anspruch nehmen.

Der Trick besteht jetzt darin, sowohl die alten als auch die neuen Versionen
der zu ändernden Metadaten (Inodes, Inode-Maps und ähnliches) auf
der Platte zu speichern.
Die alten Metadaten bleiben erst mal unverändert auf der Platte stehen,
die neuen Metadaten schreibt das Dateisystem hintereinander weg in das
Journal oder Log das sich in einem reservierten Bereich der Festplatte befindet.

Das Journal fasst dabei viele Aktionen zu einer Transaktion
(ähnlich wie bei Datenbanken) zusammen.
Dabei werden nicht nur einzelne logische Operationen (z.B. Datei anlegen)
ausgeführt sondern es werden aus Performancegründen gleich mehrere solcher Operationen ausgeführt.

Ab einem bestimmten Punkt wird eine Transaktion mit einem "Commit-Eintrag“
im Journal abgeschlossen.
In diesem Moment stehen sowohl die konsistenten alten Daten auf der Platte,
sowie schon die neuen Metadaten im Journal.
Jetzt werden die neuen Metadaten an ihre Bestimmungsorte auf der Festplatte geschrieben.

Nach einem Crash muss nun nur das Log überprüft werden, es gibt nur zwei Möglichkeiten
für eine Transaktion, entweder "committed" dann sind die Metadaten im Journal gültig
und brauchen nur an den Bestimmungsort kopiert werden.
Oder die Transaktion ist nicht "committed" dann werden die Einträge im Journal gelöscht,
die alten Werte stehen ja noch auf der Platte.

Außer bei der Mount-Option "data=journal" bei ext3 ist die Integrität der Daten jedoch noch nicht gesichert,
da sonst nur die Metadaten im Journal stehen die eigentlichen Daten jedoch nicht.
Fällt z.B. der Strom aus, während gerade eine Datei mit neuen Daten überschrieben
wird, so enthält die Datei danach neue und alte Daten vermischt.

Beim ext3-Journaling werden komplette Datenblöcke im Log abgelegt, bei einer Blockgröße
von 4 kByte werden 4 kByte ins Journal geschrieben, wenn nur ein Bit sich ändert.
Damit trotzdem nicht zuviel Schreibarbeit anfällt werden Aktionen im Speicher gesammelt
bis ein Commit ansteht. Es werden auch keine einzelnen Operationen ins Log geschrieben
sondern das Ergebnis einer gesamten Transaktion.
(z.B. werden mehrere Dateien in einem Verzeichnis erstellt so wird nur der Endzustand
mit allen neuen Dateinamen im Log festgehalten nicht das anlegen jeder Datei im Einzelnen)

Weiter steigern lässt sich die Performance indem man das Journal auf einer Platte,
das Dateisystem auf einer anderen anlegt. Dies unterstützt ext3 und so kommen sich Schreibprozesse
von Log und Daten nicht in die Quere.

2.2. Konvertieren von ext2 nach ext3

Hier will ich noch mal etwas ausführlicher auf das Konvertieren eines ext2 in ein ext3
Dateisystem eingehen.

Zuerst sollte man den Rechner in den Single-User-Modus fahren:

init S

Jetzt unmountet man am besten alle nicht benötigten Partitionen und führt für
jede zu konvertierende ext2-Partition folgendes Kommando aus:

tune2fs -j /dev/hdXX

(für hdXX natürlich den richtigen Namen der Partition z.B. hda1)

Die regelmäßige (nach 20 Mount-Vorgängen oder 120 Tagen) Überprüfung des
Dateisystems ist bei ext3 jetzt nicht mehr nötig, mit folgendem Befehl kann man sie ausschalten.

tune2fs -c 0 -i 0 /dev/hdXX

Jetzt ändert man die Einträge der Konvertierten Partitionen in der Datei /etc/fstab.
Den Eintrag ext2 ändert man am besten in auto und nicht ext3, da man so auch mit alten
Linux Kerneln den Rechner booten kann. (dann natürlich als ext2 ohne Journaling)
Als nächstes können alle Partitionen gemountet werden und der vorhergehende Runlevel
aktiviert werden (z. B. "init 3").

Will man eine ext3 Partition nach ext2 zurückführen, lautet der Aufruf von tune2fs wie folgt.

tune2fs -O ^has_journal /dev/hdXX

Nun nicht vergessen, die vorher ausgeschaltete Überprüfung nach 20 Mount-Vorgängen
bzw. 120 Tagen wieder zu aktivieren:

tune2fs -c 20 -i 120d /dev/hdXX

2.3. Nachteile von ext3

ext3 legt beim Formatieren eine feste Anzahl von Inodes an, sind alle Inodes aufgebraucht
lässt sich keine neue Datei mehr anlegen, egal wie viel Platz noch auf der Platte ist.
Jetzt gibt es nur noch die Möglichkeit alle Daten auf eine andere Partition zu kopieren,
die Partition mit den zu wenigen Inodes neu zu formatieren und dabei mehr Platz
für Inodes zu reservieren.
Ein weiterer Nachteil ist zum Beispiel, dass man keine versehentlich gelöschten
Dateien mit der undelete-Funktion zurückholen kann.
Bei sehr großen Dateien und Verzeichnissen, mit etlichen tausend Dateien
schneidet ext3 schlechter ab, als die anderen hier vorgestellten Filesysteme
(der Suchaufwand im Verzeichnis mit vielen Einträgen ist wegen der
verketteten Liste größer als beim Binärbaum).

3. JFS

Das Journaling File System JFS wurde von IBM entwickelt und existierte
schon lange Zeit im OS/2 Server.
Es gibt JFS auch als jfs2 für AIX, IBM´s eigener UNIX Version.
Man kann bei JFS mittels mkfs.jfs mit der Option „-O“ ein zu OS/2
kompatibles Dateisystem, das aber nicht zwischen Groß- und Kleinschreibung
unterscheidet anlegen.
Dann wird aber beim anlegen einer Datei TEST eine vorhandene Datei test überschrieben.
Vorzüge hat JFS bei großen Dateien, wie etwa Filmen, ansonsten ist das
Filesystem bis jetzt noch nicht so sehr stabil.
Alan Cox hat JFS in seinen Entwicklerkernel mit Version 2.4.18-pre9-ac4
integriert und möglicherweise soll JFS bald in den Linux-Kernel
aufgenommen werden, zurzeit muss man noch einen Patch von der JFS Seite einspielen.

http://oss.software.ibm.com/developerworks/opensource/jfs/index.html

JFS benutzt Journaling, variable Blockgrößen und dynamische Inode Vergabe.

3.1. Nachteile

Der Hauptnachteil ist das JFS bis jetzt noch nicht so stabil ist,
JFS hat keine Quota und keine ACL`s.

4. ReiserFS

Das Journaling Filesystem ReiserFS wurde nach seinem Entwickler Hans Reiser benannt,
der als private Studie ein, mittlerweile alltagstaugliches und leistungsstarkes, Dateisystem entwickelte.
Dateien und Verzeichniseinträge werden bei ReiserFS in einem balancierten Binärbaum angeordnet,
kleine Dateien bzw. Dateireste, Verzeichniseinträge und Verweise auf 4 kByte Datenblöcke werden
gemischt in 4 kByte Blöcken untergebracht. Dadurch wird der vorhandene Plattenplatz optimal genutzt.
Ein positiver Nebeneffekt ist das sich dadurch mehr Informationen im Buffer-Cache befinden
und weniger „echte“ Plattenzugriffe nötig sind.
Es wird darauf geachtet, das die Daten in der Nähe ihrer Verweise und Verzeichniseinträge
liegen, um große Bewegungen des Schreib/Lesekopfes zu vermeiden.
ReiserFS hielt vor einem Jahr als erstes Journaling File System Einzug in den
Standardkernel (2.4.1.).

Das Umwandeln eines ext2 Dateisystems in ReiserFS ist leider viel komplizierter als bei ext3.
Ich will hier nicht näher darauf eingehen, es gibt im Netz genaue Anleitungen dazu.
Suse hat seit seiner Version 6.4 ReiserFS als Option bei der Installation.
(Suse ist auch Sponsor der ReiserFS-Entwicklung)
Bei einer Neuinstallation gibt es natürlich keine Probleme ReiserFS zu installieren.

4.1. Nachteile

Bei vielen kleinen Dateien bricht das Dateisystem stark ein, da das speicherplatzeffiziente
Zusammenlegen von kleinen Dateien beträchtlichen Verwaltungsaufwand mit sich bringt.
Mit der Mount-Option "notail" verwaltet ReiserFS Datensplitter genauso verschwenderisch
in 4 kByte Blöcken wie die anderen Filesysteme,
aber eben deutlich schneller als in der Platz sparenden Variante.
(um mit Lilo booten zu können muss diese Option auch gewählt sein)
Ansonsten zeigt ReiserFS eine gut ausgewogene Leistung.

5. XFS

XFS ist ein Journaling Filesystem der Firma SGI.
Am 1. Mai 2001 stellte SGI das Release 1.0 des XFS für Linux zur Verfügung.
Die maximale Dateigröße mit dem Kernel 2.4. beträgt 16 TerraByte
bei 4 KByte Blöcken und bei 16 kByte Blöcken 64 TerraByte.
Bei 64 bit Linux sogar 9 PetaByte (9 Millionen TerraByte),
für die Zukunft plant man sogar die Beschränkung der Plattengröße aufheben.
XFS ist sehr gut im Umgang mit großen Dateien, mit vielen Dateien und unter hoher Last.
Ich denke es ist im Moment das leistungsstärkste Dateisystem.
XFS kennt Access Control Lists (ACLs) und erweiterte Attribute die sich Objekten im
Dateisystem zuordnen lassen. Für beides gibt es unter Linux noch keinen Standard,
die ACL`s lassen sich jedoch mit Samba benutzen.
Sowohl User als auch Group Quotas werden unterstützt.
XFS bietet auch so genannte `real-time sections´ innerhalb einer XFS-Partition,
die sich mittels mkfs.xfs anlegen lassen.
Über spezielle ioctl-Aufrufe können Anwendungen dort Daten platzieren.
Diese Daten lassen sich dann bei ungepufferten I/O-Zugriffen mit höhere Schreib-
und Leseraten benutzen. Dies wird unter IRIX mit streaming Media genutzt,
funktioniert aber unter Linux noch nicht.
Zum Dateisystem gibt es eine Vielzahl von Dienstprogrammen, wie das Manipulieren
von ACLs und erweiterten Attributen, zum Kopieren von Dateien in den
Realtime-Bereich und für die Verwaltung und Leistungskontrolle von XFS.
Es lassen sich auch Performance-Statistiken ausgeben und mittels
des "File System Reorganizer" die Daten defragmentieren

5.1. Nachteile

Beim Abschalten im laufenden Betrieb produziert XFS wie ReiserFS Dateien, die gelöschte Daten enthalten.
XFS ist leider noch nicht im Standardkernel enthalten.

6. Zusammenfassung

	ext3 (0.9.16)	JFS (1.0.15)	ReiserFS (3.6.25)	XFS (1.0.2)
Eigenschaften
baumbasiert	nein	ja	ja	ja
Extents	nein	ja	nein	ja
Datei-Fragmente	nein	nein	ja	nein
dynamische Inode-Allozierung	nein	ja	ja	ja
Volume Label	ja	ja	nein	ja
ACL´s	nein	nein	nein	ja
Blockgröße	1, 2, 4 kByte	4 kByte	4 kByte	4 kByte
max. Dateigröße	16 TByte	4069 TByte	10⁶ TByte	8,4 * 10⁶ TByte
max. Dateisystemgröße	16 TByte	4096 TByte	16 TByte	8,4 * 10⁶ TByte
Daten über 4 GB mit Linux 2.4	ja	ja	ja	ja
Hardwareplatformen	alle	ia32, ia64, PPC, Alpha, S/390,ARM	alle	ia32, ia64, PPC, Alpha, SPARC64
im Standardkernel enthalten	ja	nein	ja	nein
Journaling
externes Journaling	ja	nein	nein	ja
ganze Blöcke im Journal	ja	nein	ja	nein
Datenblöcke im Journal	ja mit mount-Option "data=journal"	nein	nein	nein
Funktionen
läuft als Root-Dateisystem	ja	ja	ja	ja
läßt sich mit Lilo booten	ja	ja	ja	ja
läßt sich mit Grub booten	ja	mit Patch	ja	mit Patch
unterstützt NFS	ja	ja Zusammenarbeit mit NFS laut IBM nicht perfekt	ja	ja
unterstützt LVM	ja	ja	ja	ja
unterstützt Soft-RAID	ja	ja	ja	ja laut SGI schlechte Performance bei RAID-5

7. Fazit

Bis auf JFS das bis jetzt noch etwas Unstabil ist, kann man jedes der Filesysteme empfehlen.
Es kommt auf den Geschmack des Einzelnen an und auf den Verwendungszweck.
Alle Dateisysteme haben ihre Vor- und Nachteile.
Für ext3 spricht seine Kompatibilität mit ext2 und die hohe Sicherheit beim Journaling.
Nur ext3 kann Sicherstellen das bei einem Crash keine alten Daten in neuen Dateien auftauchen,
auf Wunsch garantiert es sogar Datenkonsistenz.
Wenn es nur um Performance geht ist XFS die erste Wahl, leider ist XFS aber noch nicht
im Standardkernel enthalten.