Wiederherstellen eines ext2
Werbung
Projektarbeit Systemadministration < Journalierende Dateisysteme > Projektarbeit Systemadministration Thema: Journalierende Dateisysteme Bearbeiter: Lehrgang: Martin Sommer, Elvis Corbo, Patrick Schmid 12. Info an der NTA / Isny 1 Projektarbeit Systemadministration < Journalierende Dateisysteme > Gliederung 1. 1.1 1.1.1 1.1.2 Grundlagen Was sind Dateisysteme? Welche Dateisysteme gibt es? (Technik:Ur-Unix, FFS, LFS) Beispiele (ext2, ext3, reiserfs, ntfs, fat, fat32, hfs…) 2. 2.1 2.1.1 2.2 2.3 2.4 2.4.1 2.4.1.1. 2.4.1.2. 2.4.1.3. 2.4.1.4. Journalierende Dateisysteme Was bedeutet journaling? Wozu benötigt man journalierende Dateisysteme? (Inkonsistenz) Vorteile Nachteile Realisierung Protokollierung Log Structured Atomares Dateisystem Logging der Metadaten/Inodes (Beispielprotokoll) Doppeltes Schreiben 3. 3.1 3.1.1 3.1.1.1 3.1.1.2 3.1.1.3 Implementierungen ext3/ext2 mit journaling ext3 – Journalingarten writeback ordered journal 3.2 3.3 3.4 3.5 3.6 3.7 reiser FS (Linux) ntfs (Win) hfs (Mac) Vxfs (Veritas) xfs (Irix) jfs (OS/2) -> IBM 4. 4.1 4.2 Konkrete Anwendung Unterschiede der Implementierungen ext3 verwenden 5. Quellangaben 2 Projektarbeit Systemadministration < Journalierende Dateisysteme > Projektdokumentation Inhaltsverzeichnis Einleitung………………………………………………………………….……...... Seite 4 Themenabarbeitung 1. Einführung/Grundlagen.............................................................................. Seite 5 1.1 Was sind Dateisysteme?....……………………………………….….…….. Seite 5 1.1.1 Welche Dateisysteme gibt es?...............................................….................... Seite 9 1.1.2 Beispiele………………….………………………………………….…….. Seite 11 2. Journalierende Filesysteme........................................................................ Seite 13 2.1 Was bedeutet journalierend?......................................................................... Seite 13 2.1.1 Wozu benötigt man Journalierende Dateisysteme?....................................... Seite 17 2.2 Vorteile…………………………………………………………………….. Seite 17 2.3 Nachteile………………………………………………………………….... Seite 17 2.4 Realisierung………………………………………………………………... Seite 18 2.4.1 Protokollierung.............................................................................................. Seite 18 2.4.1.1 Log – structured............................................................................................. Seite 18 2.4.1.2 Atomares Dateisystem................................................................................... Seite 18 2.4.1.3 Logging der Metadaten / Inodes.................................................................... Seite 19 2.4.2 Doppeltes Schreiben...................................................................................... Seite 19 3. Implementierungen...................................................................................... Seite 20 3.1 ext3 (Linux)................................................................................................... Seite 21 3.1.1 ext3-Journalingarten...................................................................................... Seite 21 3.1.1.1 write-back...................................................................................................... Seite 21 3.1.1.2 ordered........................................................................................................... Seite 21 3.1.1.3 journal............................................................................................................ Seite 22 3.2 reiserFS (Linux)............................................................................................ Seite 22 3.3 NTFS (Windows).......................................................................................... Seite 25 3.4 hfs (Mac)........................................................................................................ Seite 27 3.5 Vxfs (Veritas)................................................................................................ Seite 30 3.6 xfs (Irix)......................................................................................................... Seite 30 3.7 jfs (OS/2)....................................................................................................... Seite 31 4. 4.1 4.2 Konkrete Anwendung................................................................................. Seite 33 Unterschiede der Implementierungen........................................................... Seite 33 ext3 verwenden…………............................................................................. Seite 34 5. Fazit............................................................................................................... Seite 36 Anhang 6. Quellangaben…………..…………………………………..……………... Seite 37 3 Projektarbeit Systemadministration < Journalierende Dateisysteme > Einleitung Das Thema unserer Projektarbeit ist die nähere Betrachtung von journalierenden Dateisystemen (engl. journaling filesystem). Journalierende Dateisysteme sind Grundvorrausetzung von Computersystemen bei denen es auf Schnelligkeit und Zuverlässigkeit ankommt. Nach einem unerwarteten Neustart kann das System einige Zeit benötigen, um seine Dateisysteme wiederherzustellen. Das wird mit wachsender Festplattengröße immer mehr zum ernsthaften Problem, da der PC während der Kontrolle und Reparatur nur offline betrieben werden kann. Bei einem Server wird jedoch eine Verfügbarkeit von 99,9% vorausgesetzt. Das entspricht 6 Stunden im Jahr, die für Wartungsarbeiten zur Verfügung stehen. Je größer die Festplatte, desto länger dauert die Wiederherstellungszeit. Deshalb ist ein Mechanismus gefragt, der die Wiederherstellung der Daten bei jedem Neustart eines Rechners hinfällig werden lässt oder erheblich verkürzt und vereinfacht. Ein journalierendes Dateisystem ist ein solcher Mechanismus, der zum einen die Rechenleistung nicht zu sehr beansprucht und bei dem zum anderen die Kompatibilität mit vorhandenen Applikationen erhalten bleibt. Um die Funktionsweise von einem Journalierenden Dateisystem verstehen zu können wird grundlegendes Wissen über Dateisysteme vorausgesetzt. Dieses Wissen wird im ersten Abschnitt zusammengefasst wiedergegeben. 4 Projektarbeit Systemadministration < Journalierende Dateisysteme > 1. Einführung / Grundlagen 1.1 Was sind Dateisysteme? Ein Dateisystem ist ein System, mit dessen Hilfe man Daten in Form von Dateien auf einem Datenspeicher (HDD, FD, MB, ...) speichert und verwaltet. Eine Datei ist also eine definierte Struktur auf dem Datenträger. Fast jedes Betriebssystem besitzt sein eigenes Dateisystem, d.h. jedes Betriebssystem legt seine Dateien nach einem anderen Schema ab. Alle Dateisysteme arbeiten mit den Elementen „Dateiname“ sowie den „Dateiattributen“ jeder spezifischen Datei. Zur Untermenge der Dateiattribute, die nähere Informationen über die Datei enthalten, gehören Größe, Lese-/Schreibrechte und Besitzrechte der Datei für einzelne User oder Gruppen. Moderne Dateiattribute sind u.a. der Dateityp (speziell bei Windows/ wird bei Linux nicht benötigt), versteckt, archiviert, wann die Datei erstellt wurde und wann die Datei zuletzt verwendet wurde. Darüber hinaus gibt es Attribute mit denen höher entwickelte Dateisysteme arbeiten können. Das Setzen von Prioritätsbits kann dem Dateisystem eines Betriebssystems z.B. mitteilen an welcher Position des Datenträgers die Datei abgelegt werden soll. Um ein Dateisystem besser untergliedern zu können werden spezielle Dateien, die Verzeichnisse verwendet. Verzeichnisse können weitere Dateien enthalten. Das Vorhandensein von Verzeichnissen ist nicht zwingend erforderlich; ermöglicht jedoch dem menschlichen Auge den Überblick zu behalten und darüber hinaus einige nützliche Funktionen: Dateibäume können z.B. durch Verzeichnisse schneller angezeigt werden. Zugriffe auf Massenspeicher Bei Massenspeichern ist die Blockstruktur weit verbreitet. Dateien werden hierbei vom Betriebssystem nicht bitweise gelesen/geschrieben sondern in ganzen Blöcken. Die früher übliche Blockgröße mit 512 Bytes ist von größeren Blockstrukturen wie 4096 oder 8192 Bytes verdrängt worden. Der Massenspeicher ist für das Betriebssystem eine große Fläche mit durchnummerierten Blöcken: Block0 Block1 Block2 Block3 4096 B 4096 B 4096 B 4096 B ... Eine Datei mit einer Größe von 5000 Bytes würde also 2 Blöcke (Block0 und Block1) belegen. Die restlichen 3192 Bytes werden verschenkt. Je nachdem ob man mit großen oder mit kleinen Dateien arbeitet sollte man sich für große oder kleine Blöcke entscheiden. Bei größeren Blöcken steigt die Zugriffsperformance. 5 Projektarbeit Systemadministration < Journalierende Dateisysteme > Die Attribute einer Datei werden nicht in den Blöcken gespeichert sondern erhalten eine Beschreibungsstruktur, die separat im Beschreibungsblock des Dateisystems abgelegt werden. Dieser Beschreibungsblock heißt auch Dateizuordnungstabelle - bei Windows FAT (= File Allocation Table). In Linux enthält der Superblock am Anfang Informationen über das gesamte Dateisystem wie Größe, Typ und Belegungsgrad. Nach dem Superblock stehen die i-nodes mit Informationen über die Dateien, die hier als Nummern geführt werden. Nach den i-nodes kommen die Indirection Blöcke, die Tabellen mit Pointern auf Datenblöcke enthalten. Auf diese folgen die Directory Blöcke. Die Directory Blöcke enthalten eine Liste mit der i-node Nummer und dem Name der Datei. Hinter den Directory Blöcken stehen dann die eigentlichen Datenblöcke mit den Daten der Dateien. Abbildung 1: I-Nodes Im Verzeichnis werden nur die Dateinamen mit entsprechenden Referenzen zum Beschreibungsblock abgelegt. Der erste Beschreibungsblock kann dabei das Ausgangsverzeichnis enthalten. Nicht belegte Blöcke werden in einer Freiliste geführt. Der erste „Block“ auf einer Festplatte ist für einen Bootblock reserviert, der Informationen zum Hochfahren des Rechners enthält. Der Bootblock ist kein Bestandteil des Dateisystems. 6 Projektarbeit Systemadministration < Journalierende Dateisysteme > Ein Beispiel für das Aussehen eines Dateisystems auf einem Massenspeicher: [Bootblock] [Beschreibungsblöcke] [Freiliste] [Datei- und Verzeichnisblöcke] Dateisystemoperationen an Dateien Will ein Programm auf einen Block zugreifen (schreiben/lesen) so erfolgt das immer indirekt über das Dateisystem. Dieses stellt über Betriebssystemaufrufe Funktionen zu Verfügung. Die wichtigsten Operationen die unter UNIX an Dateien durchgeführt werden können sind: * open, close * read, write * create, unlink * mkdir, rmdir * readdir Datei öffnen/schließen Setzen des Lese-/Schreibzeigers zum einlesen/schreiben der Datei Erzeugen und Löschen einer Datei Erzeugen und Löschen eines Verzeichnisses Verzeichniseinträge lesen Diese Systemaufrufe, die von Programmen betätigt werden, werden vom Kernel abgefangen. Im Dateisystemteil des Kernels werden die jeweiligen Befehle dann in konkrete Operationen an den Blöcken umgewandelt. Ruft ein Programm z.B. die Funktion open auf, so wird der Name der Datei in der Beschreibungstabelle gesucht und der erste Block der Datei entnommen. Der erste Block einer Datei kann auch gleichzeitig eine Blockliste sein, die in Form einer Tabelle alle Blöcke, in serieller Reihenfolge beinhaltet. Der Zugriff über eine Blockliste steigert die Performance da der Lesekopf des Massenspeichers sowieso die Möglichkeit hat mehrere Blöcke auf einmal zu lesen. Die Funktion read ermöglicht es dem Programm auf die Blöcke der Datei zuzugreifen bzw. sie in den Hauptspeicher zu laden. Die Funktion write ändert im Normalfall die Dateigröße. Wird die Datei größer, wird ein neuer Block aus der Freiliste entnommen und in die Beschreibungsstruktur übernommen. 7 Projektarbeit Systemadministration < Journalierende Dateisysteme > Inkonsistenz Dateninkonsistenz tritt auf wenn Tabelleneinträge nicht mehr zutreffen oder Blöcke vorhanden sind, auf die keine Referenzen verweisen. Dies tritt auf wenn ein Eintrag bereits geschrieben ist aber der Computer während dem Schreibvorgang der eigentlichen Daten abstürzt. In diesem Fall muss die Inkonsistenz behoben bzw. das Dateisystem repariert werden bevor weitergearbeitet werden kann. Beim Bootvorgang wird das Dateisystem einer Konsistenzprüfung unterzogen. Dabei werden die Zuordnungstabellen überprüft. Beim Durchlaufen der linearen Blocklisten einer jeden Datei lassen sich Blöcke ohne Zuordnung aufspüren. Bei MS DOS und Win9x erfolgt das über das Systemtool scandisk.exe. Das Linux – Äquivalent dazu ist fsck (beinhaltet u.a. e2fsck). Die Dauer der Überprüfung/Reparatur steigt linear mit der Größe der Festplatte und der Anzahl der darauf liegenden Dateien. Abhilfe schafft ein journalierendes Dateisystem dessen Daten anhand des Journals deutlich schneller rekonstruiert werden können. Konsistenzprüfung mit ScanDisk 8 Projektarbeit Systemadministration < Journalierende Dateisysteme > 1.1.1 Welche Dateisysteme gibt es? Hierarchische Dateisysteme Früher hatten die Dateisysteme keine Unterverzeichnisse. Alle Verweise auf Dateien wurden in einem einzigen Verzeichnis gespeichert. Dieses Verzeichnis kann man mit dem heutigen Wurzelverzeichnis vergleichen das in modernen Dateisystemen vorkommt. Die modernen Dateisysteme können in ihrem Wurzelverzeichnis sowie in allen anderen Verzeichnissen Unterverzeichnisse erstellen. -> hierarchischer Aufbau Die Verzeichnishierarchie die dadurch entsteht wird oft als Verzeichnisbaum dargestellt. Unter Windows ist das Wurzelverzeichnis gleichbedeutend mit dem Laufwerksbuchstaben (im Beispiel: Laufwerk C: ). Unter Linux wird das Wurzelverzeichnis mit einem Slash / dargestellt. Das Wurzelverzeichnis enthält unter Windows Dateien wie boot.ini sowie Verzeichnisse wie Dokumente und Einstellungen, die wiederum Unterverzeichnisse enthalten. Analoges gilt für UNIX/Linux – Systeme. Ein Vorteil des hierarchischen Aufbaus ist, dass im Dateisystem mehrere Dateien mit gleichem Dateinamen vorhanden sein können. Sie müssen sich jedoch in unterschiedlichen Unterverzeichnissen befinden. Windows 95-Me: [Laufwerk C:] +- IO.SYS +- MSDOS.SYS +- [Eigene Dateien] | +- [Eigene Bilder] | | +- Bild1.png | | | +- [Texte] | +- Brief1.txt | +- Brief2.txt | +- [Programme] Windows 2000/XP: [Laufwerk C:] +- boot.ini +- ntldr +- [Dokumente und Einstellungen] | +- [benutzername] | +- [Eigene Dateien] | +- [Eigene Bilder] | | +- Bild1.png | | | +- [Texte] | +- Brief1.txt | +- Brief2.txt | +- [Programme] UNIX/Linux: [Wurzelverzeichnis /] +- [boot] +- [etc] +- [home] |+- [benutzername] | +- [Dokumente] | +- [Bilder] | | +- Bild1.png | | | +- [Texte] | +- Brief1.txt | +- Brief2.txt | +- [usr] [Verzeichnisname] = Verzeichnis Um die Lage einer Datei im Dateibaum anzugeben benutzt man Dateipfade. Die Ordner werden durch spezielle Trennzeichen von einander getrennt. Bei DOS/Windows durch einen Backslash \ Bei UNIX/Linux durch einen einfachen Slash / Bei Macintosh durch einen Doppelpunkt : Bei Microsoft Betriebssystemen erhält jedes Laufwerk bzw. jede Partition einen Buchstaben, gefolgt von einem Doppelpunkt. Der Buchstabe und der Doppelpunkt werden Pfadangaben vorangestellt. UNIX/Linux Systeme besitzen nur einen Verzeichnisbaum in den andere Laufwerke eingehängt (gemountet) werden. 9 Projektarbeit Systemadministration < Journalierende Dateisysteme > Der Zugriff auf die Datei Brief1.txt erfolgt also wie folgt: Windows 2000/XP: C:\Dokumente und Einstellungen\$user\Eigene Dateien\Texte\Brief1.txt UNIX/Linux: /home/benutzername/Dokumente/Texte/Brief1.txt Netzwerkdateisysteme Bei Netzwerkdateisystemen werden die Systemaufrufe (open, read, write, ...) nicht nur lokal ausgeführt sondern können auch an einem Server im Netzwerk ausgeführt werden. Der Server führt die Operationen dann auf seinem eigenen Massenspeicher durch und überträgt die Änderungen dann wieder zurück zum Client. Weil sich die Systemaufrufe aus der Sicht vom Programm/Anwender nicht von normalen lokalen Systemaufrufen unterscheiden werden sie auch als transparente Zugriffe bezeichnet. Die auslösende Instanz bekommt nicht mit, ob die Operation auf der lokalen Maschine ausgeführt oder weitergeleitet wird. Spezielle Dateien und Dateisysteme Der Zugriff auf Daten mit den Dateisystemaufrufen (open, read, write, ...) funktioniert auch mit Geräten und Objekte, die eigentlich nicht über das Dateisystem angesprochen werden. Das hat den Vorteil dass sich die Zugriffe auf Geräte mit dem gleichen Modell realisieren lassen wie der Zugriff auf eine normale Datei. Der aktuelle Linux-Kernel arbeitet mit einem virtuellen proc-Dateisystem. Über dieses Dateisystem lassen sich System- und Prozessinformationen abfragen bzw. ändern. Die virtuelle Datei /proc/cpu existiert nicht wirklich. Über sie kann man aber wie aus einer normalen Datei Informationen über den Prozessor abrufen. Bei UNIX/Linux Systemen gibt es zu allen Schnittstellen äquivalente Dateien. Auf die Tastatur, die Maus und sogar auf den Hauptspeicher ( Dateiname: /dev/mem ) kann mit open, read, write, ... zugegriffen werden. Unix-Philosophie: Alles ist eine Datei, und wenn nicht, sollte es eine Datei sein 10 Projektarbeit Systemadministration < Journalierende Dateisysteme > Datenbank-Dateisysteme Dateien in einem Datenbank-Basierenden Dateisystem werden nicht hierarchisch verwaltet. Stattdessen werden sie anhand von Eigenschaften (Dateityp, Autor, usw.) angesprochen. Daraus ergeben sich vielseitige Möglichkeiten bei der Dateisuche mit SQL oder durch Angabe mehrerer Eigenschaften wie „Film“ über „China“. GNOME Storage und WinFS sind erste Entwicklungen von Datenbank-Basierenden Dateisystemen. 1.1.2 Beispiele Filesysteme von CP/M, Apple DOS, Commodore DOS (ohne Namen) Modernere Betriebssysteme: DOS: * FAT bzw. FAT12 (File Allocation Table, für Disketten) * FAT16 (Erweitertes FAT-System für Festplatten) * FAT32 (Erweitertes FAT für große Festplatten) MS-Windows unterstützt sämtliche DOS-Dateisysteme, zusätzlich: * VFAT (Virtual FAT: längere Dateinamen für alle FAT-Systeme) * NTFS (journaling filesystem von Windows NT und Nachfolgern) * WinFS (Datenbank-Basierendes Dateisystem) Linux/UNIX: * minix (minix - Distribution) * ext2 (second extended file system, lange Zeit das Linux-Standard-Dateisystem) * ext3 (weiterentwickelte Variante von ext2 mit journaling) * ReiserFS (Linux Journaling File System) * JFS (Journaled File System von IBM) * UFS (UNIX File System unter Solaris und BSD) * XFS (Journaling Filesystem von SGI) * xFS (Netzwerk-Dateisystem) * NFS Network File System (von Sun für Solaris entwickelt) * SYSV (System V Filesystem von AT&T) * ADFS * GNOME Storage (Datenbank-basierendes Dateisystem) 11 Projektarbeit Systemadministration < Journalierende Dateisysteme > AmigaOS: * FFS (Amiga Fast File System) Apple Macintosh * ProDOS (Dateisystem der späten Apple II-Modelle) * MFS (Macintosh File System) * HFS (Hierarchical File System) * HFS+ (Erweiterung von HFS u. a. auf Dateinamen mit mehr als 32 Zeichen) * HFSX Case sensitive Variante von HFS+ OS/2: * HPFS (High Performance File System) * JFS (Journaled File System) BeOS/Haiku: * BFS * OpenBFS (64 Bit, multithreaded, journalierendes, Datenbank-ähnliches Dateisystem) CD-ROM/DVD: * ISO9660 (Dateisystem für CD-ROMs) * Joliet (Erweiterung des ISO9660 von der Firma Microsoft) * Rockridge (Erweiterung des ISO9660 für UNIX) * UDF (Universal Disk Format, u. a. auf DVDs) Netzwerk: * NFS (Network File System; ein über Netzwerke angeschlossenes Dateisystem v. a. für Unix-artige Systeme) * Coda (ein fortgeschrittenes Netzwerk-Dateisystem ähnlich zu NFS) * Samba (ein über Netzwerke angeschlossenes Dateisystem vor allem für WindowsSysteme) * xFS (ein verteiltes und dezentrales Netzwerk-Dateisystem) * AFS (Andrew File System) * NCP (NetWare Core Protocol) * DFS (distributed file system der Open Group, eine Weiterentwicklung des Andrew File System; dieselbe Abkürzung bezeichnet das gleichnamige System von Microsoft) 12 Projektarbeit Systemadministration < Journalierende Dateisysteme > 2. Journalierende Dateisysteme Ein Dateisystem benötigt interne Verwaltungs-Strukturen, welche die eigentlichen Daten der Festplatte organisieren und griffbereit halten. Solche internen Strukturen werden Metadaten genannt und sind sozusagen die Daten über die Daten. Die Metadaten definieren z. B. wo die Datenblöcke einer Datei zu finden sind, wer Besitzer ist, die Rechte, die letzten Zugriffszeitpunkte und anderes mehr. Traditionell schreiben Unix-Dateisysteme Metadaten teilweise asynchron, was im regulären Betrieb für eine deutliche Beschleunigung sorgt, im Fall eines Systemabsturzes aber eine aufwändige Überprüfung des gesamten Dateisystems notwendig macht. Da die durchschnittliche Größe von Festplatten im Verhältnis zum Datendurchsatz in den letzten Jahren überproportional gestiegen ist, hat sich die Dauer eines Filesystemchecks stark verlängert, er kann mehrere Stunden beanspruchen. Das ist bereits bei einem unbeaufsichtigten Reboot sehr störend, vor allem wenn ein nicht automatisch zu behebender Fehler einen manuellen Eingriff erforderlich macht. 2.1 Was bedeutet journaling? Aus diesem Dilemma führen zwei Wege: Entweder muss das Dateisystem die Verwaltungsstrukturen auf der Festplatte trotz verspäteten Rückschreibens immer konsistent halten oder alle Veränderungen sofort sequenziell in einem fortlaufenden Journal oder Log protokollieren. Unter den Dateisystemen, die ein Log führen, kann man zwischen zwei Typen unterscheiden: Journaling-Dateisysteme verwenden das sequenzielle Log nur temporär zum Protokollieren von Änderungen; sie schreiben die Daten später in die eigentliche Dateisystem-Organisation zurück. Log-structured-Dateisysteme verwenden das Log für die eigentliche Dateisystemorganisation; ein Zurückschreiben ist also nicht nötig. Nachteilig ist hier jedoch die starke Fragmentierung der Dateien. Bei jeder Dateimodifikation werden die Daten weiträumig auf der Platte verteilt. Schreibende Zugriffe auf die Festplatte werden hier, wie bei Datenbanksystemen, in Transaktionen zusammengefasst. Eine Transaktion ist eine Menge von einzelnen Operationen, die bestimmte Eigenschaften haben. Die sogenannten ACIDEigenschaften (Atomicity, Consistency, Isolation und Durability): Atomicity Alle Aktionen einer Transaktion finden in einem einzigen, unteilbaren Schritt statt; ein fehlgeschlagener Schritt lässt sich rückgängig machen. Consistency Jede Transaktion arbeitet und belässt die Datenbank in einem konsistenten Zustand. Isolation 13 Projektarbeit Systemadministration < Journalierende Dateisysteme > Transaktionen beeinflussen sich nicht gegenseitig. Durability Ist eine Transaktion abgeschlossen, sind die Aktionen garantiert beendet, d.h. ein nachfolgender Systemabsturz wird auf die Änderungen keinen Einfluss mehr haben. Die in diesem Zusammenhang wichtigsten sind, dass die Operationen atomar (Atomicity) und abgegrenzt (Isolation) sind. Dies bedeutet, dass diese Operationen innerhalb einer Transaktion fehlerfrei durchgeführt oder aber ohne Änderungen zu bewirken abgebrochen werden. Diese Operationen können also auch nicht nur teilweise durchgeführt werden. Hier gilt dann "Alles" oder "Nichts". In Datenbanksystemen werden diese Transaktionen im Log protokolliert. Es werden aber nicht nur die Namen der Operationen in dieses Log geschrieben, sondern auch die Inhalte, die durch diese Operationen geändert werden. In Journaling Filesystemen werden nur die Metadaten wie z.B. Inodes, Inode-Maps und ähnliches protokolliert. Abbildung 2: Schreibvorgang ohne Journaling 14 Projektarbeit Systemadministration < Journalierende Dateisysteme > Abbildung 3: Schreibvorgang mit Journaling Zusätzlich zum Journaling benutzen die journalierenden Dateisysteme Binärbäume oder balancierte B-Trees anstatt (verketteter) Listen für die Verwaltung der Inode- und BlockAllokationstabellen. 15 Projektarbeit Systemadministration < Journalierende Dateisysteme > Abbildung 4: Baum vs. Liste Im Gegensatz zu blockbasierten Dateisystemen tauchen nun auch Extents auf, um auf Datenblöcke zu zeigen. Extents sind Block-Länge-Paare, die eine effiziente Verwaltung einer großen Zahl aufeinander folgender Blöcke ermöglichen. Abbildung 5:Unterschied Blöcke und Extents 16 Projektarbeit Systemadministration < Journalierende Dateisysteme > 2.1.1 Wozu benötigt man journalierende Dateisysteme? Daten werden nicht sofort auf den Datenträger geschrieben, sondern aus PerformanceGründen zunächst im Arbeitsspeicher gehalten. Für die Anwendungen gelten die Daten aber schon in diesem Zustand als gespeichert, damit diese zügig weiterarbeiten können. Im Arbeitsspeicher wird zusätzlich die Reihenfolge der Schreibzugriffe so umgestellt, dass möglichst viele Schreibzugriffe auf einmal durchgeführt werden können. Die Daten werden anschließend, mit einer gewissen zeitlichen Verzögerung, in einem Rutsch auf die Festplatte geschrieben. Dieses als Caching bezeichnete Verfahren ermöglicht ein wesentlich schnelleres Arbeiten. Fällt nun aber plötzlich der Strom aus, ist nicht klar, in welchem Zustand die Daten gerade waren. Sind sie auf die Platte geschrieben oder waren sie noch im Arbeitsspeicher? Deshalb ist in solch einem Fall ohne Journaling eine Prüfung aller Dateien notwendig, was bei größeren Festplatten sehr lange, bis zu mehrere Stunden, dauern kann. Dies ist für Produktiv-Systeme in der Regel nicht akzeptabel. Darüber hinaus kann bei Inkonsistenzen ein manueller Eingriff notwendig werden, schlimmstenfalls lässt sich das Dateisystem nicht mehr reparieren, was allerdings sehr selten vorkommt. Das Journaling-Dateisystem vermeidet derartig lange Dateisystem-Prüfungen. Darüber hinaus werden die genannten Inkonsistenzen, die in seltenen Fällen das Dateisystem zerstören können, meist vermieden. 2.2 Vorteile – – – Im Falle eines Systemausfalls brauchen nur die betroffenen Dateien (die vor dem Ausfall geöffneten Dateien) überprüft und evtl. repariert werden. Datenkonsistenz deutlich besser Filesystem ist immer in einem genau definierten Zustand 2.3 Nachteile – – Performanceverlust Daten müssen zweimal geschrieben werden: in Log-Datei und an Bestimmungsort 17 Projektarbeit Systemadministration < Journalierende Dateisysteme > 2.4 Die Realisierung 2.4.1 Protokollierung Kernpunkt beim Journaling ist das Verwalten eines Logs für die entsprechende Partition. In diesem Log werden nur Schreiboperationen gespeichert. Das Log dient allerdings nicht dazu, generell Protokoll zu führen, denn im Prinzip ist nur wichtig, was gerade im Moment erledigt werden soll. Sobald ein Schreibvorgang abgeschlossen ist, kann seine Protokollierung verworfen werden. Die Informationen im Log werden nur ausgewertet, wenn solche Vorgänge nicht zu Ende geführt wurden. 2.4.1.1 Log-Structured Diese Dateisystemart hat trotz anderer Methodik den gleichen Effekt wie Data Journaling - alte Daten werden per Definition erstmal nicht überschrieben; zu schreibendes wird schließlich stets linear angehängt. Bei einem Ausfall muss beim Einhängen nur festgestellt werden, bis zu welchem Punkt alles konsistent ist - dieser Punkt wird als ”Checkpoint“ beschrieben. Mit zwei ”Checkpoint Regions“ an fixer Position lässt sich der letzte Checkpoint herausfinden. Die Checkpoint Regions werden abwechselnd beschrieben, um auch mit einem Ausfall beim Schreiben des Checkpoints fertig zu werden. Dabei wird neben den Zeiger auf das letzte beschriebene Segment und den globalen Daten (Inode-Map) der Zeitpunkt zuletzt abgelegt. Beim Einhängen wird dann die jeweils aktuellere Region herangezogen. Checkpoints müssen nicht allzu häufig passieren, denn ab dem Checkpoint kann das Log bei der Wiederherstellung der Reihe nach ausgewertet werden. Dazu müssen im Log zusätzlich zu erstellten Inode- und Verzeichniseinträgen vorneweg angekündigt werden. Ansonsten könnte beim Verlust von einem der beiden durch einen Ausfall der Referenzzähler der Inode nicht mehr stimmen - neue Inode und Verzeichniseinträge nach einem Checkpoint müssten verworfen werden. Dieses Konzept ist wohl als das robusteste zu bezeichnen. 2.4.1.2 Atomare Dateisysteme Schreibende Zugriffe auf die Festplatte werden hier, wie bei Datenbanksystemen, in Transaktionen zusammengefasst. Eine Transaktion ist eine Menge von einzelnen Operationen. Das wichtigste ist, dass die Operationen atomar und abgegrenzt sind. Dies bedeutet, dass diese Operationen innerhalb einer Transaktion fehlerfrei durchgeführt oder aber ohne Änderungen zu bewirken abgebrochen werden. Diese Operationen können also nicht nur teilweise durchgeführt werden sondern komplett oder gar nicht. Ein Klassisches Beispiel ist bei der Bank zu finden. Wird Geld von einem Konto auf das andere transferiert, so sollte das Geld nur abgebucht werden, wenn es auch auf der anderen Seite eingezahlt wird. Auch hier ist Journaling notwendig um auszuschließen, dass nur ein Teil des Vorgangs ausgeführt wird. 18 Projektarbeit Systemadministration < Journalierende Dateisysteme > 2.4.1.3 Logging der Meta-Daten In den meisten Fällen reicht es aus, im Protokoll nur die Operation zu beschreiben, nicht aber deren Inhalt. So wird z.B. protokolliert, dass eine Inode angelegt wird, dass sie in einem Verzeichnis referenziert wird, welche Rechte sie bekommt, wem sie gehört, etc. Des Weiteren natürlich auch, welche Blöcke sie belegen soll. Was in diese Blöcke gespeichert wird, ist im Protokoll nicht enthalten. Sichergestellt wird damit, dass das Dateisystem an sich konsistent bleibt; die gerade behandelten Daten können aber verloren gehen. So könnte ein Protokolleintrag aussehen, wenn eine Inode mit der Nummer 777 und den Datenblöcken 3110, 3111 und 3506 verändert und dabei erweitert wird: Inode 777: Block 3111: Block 3506: Block 3790: Block 3791: Inode 777: Inode 777: 16-JAN-2005 Inode 777: 16-JAN-2005 Inode 777: intent-to-commit data update (changes) data update (changes) data update (changes) data update (changes) update data block list to 3110, 3111, 3506, 3790, 3791 access time 10:12 modification time 10:12 committed 2.4.1.4 Doppeltes Schreiben Unter dem Begriff “Data Journaling“ (oder auch ”Full Journaling“) beschreibt man das Protokollieren des gesamten Vorgangs, inklusive der behandelten Daten. Damit erreicht man, dass beim Überschreiben von Daten zumindest das Original nicht verloren geht. Will man atomar arbeiten, ist es erforderlich, die entsprechenden Daten doppelt zu schreiben. Dabei werden sie erst im Log aufgefüllt, um dann nochmals an ihr wirkliches Ziel geschrieben zu werden. Dabei wird sichergestellt, dass alte Daten nur dann überschrieben werden, wenn die neuen auch wirklich komplett vorhanden sind. 19 Projektarbeit Systemadministration < Journalierende Dateisysteme > 3. Implementierungen 3.1 ext3 Stephen Tweedie entwickelte für das Linux Dateisystem ext2 eine Erweiterung. Diese Erweiterung macht aus dem normalen ext2 Dateisystem ein journalierendes Dateisystem, ext3 (extended filesystem 3) genannt. Das neue Dateisystem verzichtet vollkommen auf das Ausführen von e2fsck das nach einem Rechnerabsturz das komplette Dateisystem auf Fehler überprüft und diese dann behebt. Da ext3 genau genommen eine Erweiterung des alten ext2 ist, ist es auch vollkommen abwärtskompatibel. Bestehende ext2 Systeme können ohne Verlust einfach und schnell auf ext3 umgestellt werden. Das Mounten von einem bestehenden ext3 System als ein ext2 Dateisystem ist ebenfalls möglich da das Datenformat des Datenträgers nicht verändert wird. Die Metadaten, die bei einem journalierenden Dateisystem benötigt werden, werden in einer normalen Datei geführt, dem Journal. Diese Datei befindet sich auf der ext3 Partition im root-Verzeichnis und heißt .journal. Wird eine Dateisystemoperation durchgeführt (z.B. eine neue Datei erstellt) wird sie nicht sofort im i-node Block ausgeführt sondern vorerst als Transaktion in der .journal eingetragen. Diese Transaktionen werden nach dem atomic-Prinzip als angesehen (erfolgreich) oder nicht abgeschlossen (bei Absturz) angesehen. Ist eine Operation im Journal nach einem Absturz als abgeschlossen beendet worden, ist garantiert, dass an dieser Transaktion beteiligte Blöcke einen gültigen Dateisystemstatus besitzen. Diese Blöcke werden dann einfach in den i-node Block übernommen. Wurde die Transaktion nicht als abgeschlossen ins Journal geschrieben kann keine Konsistenz garantiert werden. Eine solche Transaktion wird daher verworfen – die Änderung am Dateisystem geht dabei verloren. Das kann zu dem Problem führen, dass eine Datei zum Teil aus neuen und aus alten Blöcken besteht (falls der Rechner bei einer Schreiboperation abstürzt, die bestehende Blöcke ändern soll). Um diese Fehler zu beheben besitzt ext3 einen besonderen Modus, in dem dicht neben der Transaktion auch ganze Daten im Journal abgelegt werden. Das bedeutet jedoch nicht dass keine Daten verloren gehen können, es bleibt aber ein konsistenter Datenbestand vorhanden. Fällt das System aus, muss vor dem Weiterarbeiten die Datenkonsistenz gesichert sein. Deshalb gleicht der Kernel beim booten das Dateisystem mit den in der .journal aufgeführten Transaktionen ab und behebt Abweichungen. 20 Projektarbeit Systemadministration < Journalierende Dateisysteme > EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. kjournald starting. Commit interval 5 seconds EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 92k freed Adding Swap: 530136k swap-space (priority -1) EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. Beim Laden des Kernels wird ein Absturz erkannt und das Dateisystem wiederhergestellt. 3.1.1 ext3 – Journalingarten Es gibt drei verschiedene Möglichkeiten wie bei ext3 die Protokollierung des Journals erfolgen soll: data=write-back, data=ordered und data=journal. Das wird beim Mounten angegeben. 3.1.1.1 write-back Write-back ist die “nachlässigste” Art des Journalings. Systeme deren Protokollierung im write-back Modus durchgeführt wird sind im Vergleich zu Systemen mit ordered- oder journal – Protokollierung schneller, resultierend aus dem geringerem Performanceverlust. Es werden lediglich die Metadaten protokolliert unabhängig vom Schreiben der Daten an sich. Die Verwaltungsstruktur bleibt zwar konsistent – gerade veränderte Daten können aber beschädigt werden. 3.1.1.2 ordered Die ordered Protokollierung ist standardmäßig voreingestellt und wird deshalb am häufigsten verwendet. Auch hier werden nur Metadaten protokolliert. Log, Metadaten und Inhalte werden allerdings synchron geschrieben. Korrupte Daten können beim Überschreiben von Datenblöcken entstehen. Dabei kann man nicht einmal feststellen welche Blöcke überschrieben wurden und welche nicht, weil die Reihenfolge, in der die Blöcke geschrieben werden von der Festplatte selbst geregelt wird. Dieser Fehler tritt jedoch äußerst selten auf. Deshalb ist der ordered – Modus einen guten Kompromiss zwischen dem write-back und dem journal Modus. 21 Projektarbeit Systemadministration < Journalierende Dateisysteme > 3.1.1.1 journal Beim journal Modus wird im Gegensatz zu den anderen Modi einfach alles protokolliert. Zunächst werden die Transaktionen – wie bei write-back und ordered - im Journal vermerkt. Zusätzlich werden im Journal die zu schreibenden Daten mitgeführt. Zuerst werden die Daten ins Journal und dann erneut an ihren Zielort geschrieben. Erfolgt während diesem Vorgang ein Ausfall des Rechners, können die „verlorenen“ Daten anhand des Journals rekonstruiert werden. Der journal – Modus ist am sichersten; benötigt aber wesentlich mehr Performance wegen dem doppelten Schreiben. 3.2 ReiserFS Das Dateisystem wurde 1999 von der Gruppe um Hans Reiser (Namesys) um seine Journaling-Funktionalitäten erweitert und war somit das 1. System für Linux mit journaling. Das bevorzugte Einsatzgebiet dieses Dateisystems liegt in Systemen mit großen Verzeichnissen, die viele kleine Dateien enthalten (News-Server). Eher unangebracht ist es in Bereichen, an denen oft Dateien erzeugt und gelöscht werden, da gerade beim Löschen große Performanceeinbußen zu sehen sind. Das ReiserFS verwendet eine (balancierte) B*-tree-Struktur, um die Daten zu verwalten: Anders als bei ext2, das die Dateien quasi in einer Kette, ein Eintrag hinter dem anderen verteilt, liegt bei B-Trees Systemen eine baumartige Struktur zugrunde. Dieses Feature dient eigentlich nur der Performance. Die Besonderheit des B*-Baumes liegt darin, dass die eigentlichen Dateneinträge nur in den Blattknoten des Baumes gehalten werden. Die Nicht-Blattknoten (oder Indexknoten) enthalten lediglich Verzweigungsinformationen. Damit erhöht sich bei gleicher Eintragszahl der Verzweigungsgrad des Baumes, was zu einer Verringerung seiner Höhe führt. Darüberhinaus können die Blattknoten miteinander verlinkt und somit sequentiell durchlaufen werden. Ein weiterer Vorteil liegt in der dynamischen Vergabe von Inodes. Dies verschafft dem Dateisystem eine größere Flexibilität gegenüber herkömmlichen Dateisystemen, wie z.B. Ext2, wo die Inode-Dichte zum Zeitpunkt der Erstellung des Dateisystems angegeben werden muss. 22 Projektarbeit Systemadministration < Journalierende Dateisysteme > Es gibt versch. Journal-Modi, die ReiserFS unterstützt: 1. data = journal: Diese Option, bei der alle Daten zunächst in den Journal-Bereich kopiert werden und erst dann an den eigentlichen Bestimmungsort, garantiert höchste Datensicherheit. Mit ihr sinkt aber die Datendurchsatzrate beinahe auf die Hälfte, da jeder Schreibvorgang doppelt so lange dauert. 2. data = ordered (Standard): Das Dateisystem schreibt zunächst die Daten an den Bestimmungsort und trägt dann die Informationen über den abgeschlossenen Vorgang im Journal ein. -> Es werden nur die Metadaten (Informationen über die Bewegungen im Dateisystem) im Journal gespeichert, die eigentlichen Daten nicht. 3. data = writeback (> Kernel 2.6): Dateisystem darf bereits in das Journal schreiben, bevor alle Daten an ihrem Bestimmungsort anglangt sind. Bei einem Crash kann es vorkommen, dass durch den Dateisystemcheck alte Daten in Dateien auftauchen. 4. data = notail: ReiserFS benutzt Leerraum in Blöcken, um darin Teile von Daten zu speichern, die nicht in einen Block passen. Der Schwanz (engl. tail) der Datei wird also abgeschnitten und in einem anderen Block gespeichert. Dadurch können mehr Dateien auf derselben Partition/Platte gespeichert werden, gleichzeitig aber auch Performanceverlust. Mit dieser Option wird der Modus also abgeschaltet -> notail. Abbildung 6: Kernelmeldung beim Bootvorgang Das ReiserFS-Log besteht aus einer Reihe von Transaktionen, die append-only geschrieben werden. In linux/reiserfs_fs.h findet man die Strukturen, die Beginn und Ende einer Transaktion markieren; sie liegt folgendermaßen auf der Platte: description block (struct reiserfs journal desc) data block data block ... ... commit block (struct reiserfs journal commit) 23 Projektarbeit Systemadministration < Journalierende Dateisysteme > Dieser grundsätzlich simple Aufbau sichert die Konsistenz des Logs auch und gerade dann, wenn der Datenstrom durch einen Crash abgebrochen ist. Warum? Der Schlüssel liegt im append-only und im commit block. Das Ende des Logs wird durch einen atomic write ohne Nutzdaten markiert, es bedarf dafür keiner weiteren Verwaltungsstruktur. Ein Log (d.h. seine letzte Transaktion) hat stets einen eindeutigen Status, der durch den commit block bestimmt wird: Er ist beim Replay, also dem Zurückschreiben auf die Platte, entweder vorhanden oder nicht. In beiden Fällen ist das Vorgehen klar: Description block und commit block sind gültig. Alle data blocks dazwischen sind gültig, da sie vor dem commit block geschrieben wurden (append-only). Ob sie im eigentlichen Dateisystem bereits angekommen waren, ist egal; das Replay wird sie auf jeden Fall erneut schreiben. Description block ist gültig, commit block fehlt. Alle data blocks der Transaktion sind ungültig. Das Replay schreibt sie nicht ins Dateisystem. Da sie dort sowieso noch nicht angekommen waren, ist die Konsistenz auch in diesem Fall gesichert. Welcher Teil des Logs (description block, data block, commit block) auch immer unvollständig ist, es gibt keine Probleme für das Dateisystem, da allein der Status des commit blocks ausschlaggebend ist. Fehlt er oder ist er unvollständig, hat das Dateisystem den Stand vor der Transaktion, ist er vorhanden, den Stand nach der Transaktion. Zu beachten ist, dass der Logging-Code überhaupt keine Kenntnis über den eigentlichen Zweck der data blocks hat. Die übergeordneten Routinen müssen die Metadaten also derart in Transaktionen gliedern, dass der Status des Dateisystems mit jeder kompletten Transaktion konsistent bleibt. Für die Vollständigkeit einer einzelnen Transaktion sorgt das Logging auch und gerade dann, wenn durch einen Crash unvollständige Daten im Log stehen. 24 Projektarbeit Systemadministration < Journalierende Dateisysteme > 3.3 Das NTFS Dateisystem NTFS steht für "New-Technologie-File-System". Da Windows NT für den Professionellen Einsatz entwickelt worden ist, war es aufgrund der völlig mangelhaften Eignung und der Nachteile von FAT unentbehrlich ein neues, modernes Dateisystem für dieses damals neues Betriebssystem zu entwickeln, das diesen Ansprüchen gerecht wird. Herausgekommen ist das NTFS-Dateisystem. NTFS läuft nur als Grundlage unter einem NT-basierten Betriebssystem wie Windows NT3.5/4 oder dem Nachfolger Windows 2000 (NT 5) oder jetzt mittlerweile auch Windows XP. Technisches: Im Gegensatz zu FAT oder FAT32 basiert NTFS auf 64bit Datenbreite. Daraus ergeben sich real Partitionen von bis zu 2 Terrabyte, theoretisch sogar 16 Exabyte. NTFS bedient sich einen besonderen und verbesserten Indexsystem namens MFT (Master-File-Table). Dieses bürgt für einen besonders sicheren Umgang mit sämtlichen auf der jeweiligen Partition befindlichen Dateien, was sowohl die Wiederherstellung oder Datenrettungs- Möglichkeiten, als auch die sicherheitstechnischen Aspekte betrifft. Die MFT befindet sich auf jeder NTFS Partition. Aufbau: Ein formatiertes NTFS Laufwerk ist wie folgt aufgebaut: PBS: beginnt bei Sektor 0 und kann bis zu 16 Sektoren lang sein (16*512 b = 8192 bytes) und ist wichtig für Start und Zugriffe eines Laufwerks. MFT ist diejenige Datei, die auf NTFS - Laufwerken sämtliche Informationen über alle auf dem Datenträger existierenden Dateien und Ordner enthält. Die Größe dieser Datei ist allerdings begrenzt, was dazu führt, dass die Rechnerleistung bei Dateioperationen etc. nachlässt, wenn sich viele Dateien auf dem Datenträger befinden. 12,5% der Partition sind standardmäßig für das MFT reserviert (25% , 37,5% und 50% sind durch Veränderung der Registrierung möglich). 12,5% -> Standard 25% -> bei Workstations 37,5% -> bei Servern 50 % -> bei High-End Servern 25 Projektarbeit Systemadministration < Journalierende Dateisysteme > Beispiel für eine einfache MFT Struktur: Vorteile: Windows NT ist für den professionellen Einsatz in Netzwerken, auf BusinessWorkstations, oder/und als Server konzipiertes und optimiertes Betriebssystem. Der Sicherheits- und Datenschutzaspekt nimmt deshalb für diese Bereiche eine entscheidende Rolle ein. NTFS ist hierfür ausgelegt, da es von einem Systemadministrator so konfiguriert werden kann, dass andere, nicht- oder nur eingeschränkt befugte Benutzer, egal ob im Netzwerk oder lokal am konkreten Rechner nur auf bestimmte, vom Administrator für diese Personen freigegebenen Daten Zugriff erhalten. Daten können also bei Bedarf abgeschottet werden. NTFS ist außerdem in der Lage, beschädigte Sektoren frühzeitig zu erkennen und die dort befindlichen Daten rechtzeitig von dort in unbeschädigte Sektoren zu verschieben. Die Fehlerbehebung auf Dateiebene Check-Disk (chkdsk) arbeitet recht zuverlässig. NTFS speichert (protokolliert) sämtliche Änderungen an Dateien sowie Verzeichnissen. Dadurch könne diese bei Bedarf leicht rückgängig gemacht werden. Noch ein weiterer Vorteil ist die Verschlüsselung auf Dateisystemebene mit EFS (Encrypting File System). EFS ist kein eigenes Dateisystem, sondern nur eine spezielle Funktion neuerer NTFS-Versionen. Im Klartext bedeutet das, dass man entweder Windows 2000 oder XP einsetzen müssen wobei Microsoft die Verschlüsselung nur XP Professional anbietet, die XP Home Version hat dieses Feature nicht. 26 Projektarbeit Systemadministration < Journalierende Dateisysteme > Nachteile: Die genaue Funktionsweise ist ein Betriebsgeheimnis von Microsoft. NTFS ist ein nur auf Windows NT basierendes Betriebssystem. Es ist nur bedingt kompatibel zu Linux. NTFS ist nicht kompatibel zu DOS. 3.4 HFS+ (Hierarchical File System) HFS (Hierarchical File System) ist das klassische Dateisystem unter MacOS, das den Einzug in OS X insofern nicht mehr gefunden hat, als dass das System nicht mehr auf HFS-Volumes bootfähig ist. Das Problem war aber, dass das Volume nur in 65536 Blöcke bzw. später in sogenannten Clustern geteilt war. Dividiert man die Speicherkapazität einer modernen Festplatte durch 65536, so sieht man, wie groß ein Block wird. Auf einer HD mit 9 GB sind es immerhin schon 170 KB, die für eine Datei verbraucht werden, auch wenn sie nur 1 KB an Daten enthält. Ein Block kann nur mit einer Datei beschrieben werden, der restliche Platz ist also verschwendet. Aus diesem Grund führte Apple mit Mac OS 8.1 das Format HFS+ ein, das dieses Problem auf lange Zeit hin löst. Die Anzahl der Blöcke wurde auf 4.294.967.296 erhöht, weswegen kleinere Dateien auch weniger Festplattenspeicher belegen. Zugrunde liegt dem ganzen System die Einteilung in versch. B-trees, welche eine schnelle und effiziente Suche im Verzeichnisbaum ermöglichen. Apple entwickelte erst relativ spät, Ende 2002, ihre eigene Journaling-Technologie, die sie „Elvis“ nannten. So wurde ein Journaling erst mit dem Release von MacOS X 10.2.2 eingeführt. Es kann nun einfach über ein GUI ein- und ausgeschaltet werden. (vgl. ext2/3) Journal Die meisten Datenstrukturen eines HFS+ Volumes hängen nicht von der Größe eines Sektors ab, abgesehen vom Journal. Weil dieses Journal auf versch. Sektoren zugreift, wird die Sektorengröße im Feld „jhdr_size“ des journal header gespeichert. Auch hier werden wieder Transaktionen betrachtet. Wenn alle Einträge einer Transaktion abgearbeitet wurden (also die Änderungen auf die Platte geschrieben wurden), wird die Transaktion als abgeschlossen (comitted) angesehen und vom Journal entfernt. Das Journal kann mehrere Einträge enthalten. Den Vorgang, bei dem die Änderungen einer Transaktion an ihre „normale“ Position auf der HD geschrieben werden, bezeichnet man als Replay. 27 Projektarbeit Systemadministration < Journalierende Dateisysteme > [ Abbildung 7: Übersicht eines HFS+ Journal Das Journal baut auf dem journal info block, dem journal header und dem journal buffer auf. Der journal info block beinhaltet die Position im System und Größe des journal header und journal buffer. Der journal buffer ist für die Speicherung der Transaktionen vorgesehen. Der journal header enthält Informationen darüber, welche Teile des journal buffer aktiv sind und welche Transaktionen davon als committed vermerkt sind. Der journal info block selbst ist in einer Datei gespeichert („journal_info_block“) und befindet sich im Wurzelverzeichnis. Journal header und journal buffer sind zusammen in einer Datei „.journal“ ebenfalls im Wurzelverzeichnis zu finden. 28 Projektarbeit Systemadministration < Journalierende Dateisysteme > Transaktion Abbildung 8: Einfache Transaktion im journal buffer Eine einzige Transaktion besteht aus mehreren Blöcken, die die zu schreibenden Daten und den Ort, an dem die Daten gespeichert werden, beschreibt. Der sog. block list header hält dazu die nötigen Blocknummern und -größen, mit samt den Inhalten, bereit. Der journal buffer wird ständig nach aktiven Teilen (abgeschlossenen Transaktionen) durchsucht. Das Replay tritt in Kraft und schreibt die Daten in die passenden Blöcke auf der Platte -> Konsistenz der Daten wird somit gewährleistet. 29 Projektarbeit Systemadministration < Journalierende Dateisysteme > 3.5 VXFS (Veritas XFS) Ein Dateisystem von Veritas, das schon etwa 1985 mit einem Journaling entwickelt wurde. Bis jetzt kann es auf einen aktiven Benutzerkreis zurückblicken. Es unterstützt Quotas, ACLs (max. 25 Einträge/Datei) sowie erweiterte Attribute. Es kennt zwei zusätzliche Journal-Optionen: 1. mincache = closesync 2. mincache = tmplog Die erste Option ist für Desktop-Systeme gedacht. Sie schreibt damit die Daten beim Speichern durch den Benutzer sofort auf die Platte. Es verhindert so, dass bei einem versehentlichen Abstellen des Rechners Daten verloren gehen. Die zweite Option ist für temporäre Verzeichnisse gedacht und bewirkt, dass VXFS das Journal so selten wie möglich nachträgt. Veritas kann zudem Momentaufnahmen von VXFS-Dateisystemen speichern (Snapshot), um trotz laufenden Betriebs ein Backup zu erstellen. 3.6 XFS (Extended Filesystem) XFS ist von der Firma SGI (Silicon Graphics, Inc.) und wurde zunächst (1994) nur auf dem eigenen IRIX-BS eingesetzt. Seit 2001 auch offiziell als Linux-Dateisystem anerkannt. Geeignet ist es für Anwender, die eine große Funktionsvielfalt wünschen. Gleichzeitig bietet es einen guten Kompromiss zwischen Stabilität und Performance, bei vielen kleinen Dateien als auch beim Umgang mit sehr großen Dateien im GB-Bereich. Auch diesem Dateisystem liegt die Verwaltung der Dateien einer baumbehafteten Struktur zugrunde -> B+ Trees. Besonderheiten Hohe Skalierbarkeit durch den Einsatz von Allocation groups: Zum Erstellungszeitpunkt eines XFS-Dateisystems wird das dem Dateisystem zugrundeliegende Block-Device in acht oder mehr lineare Bereiche gleicher Größe unterteilt. Diese werden als „allocation groups“ bezeichnet. Jede Allocation group verwaltet Inodes und freien Speicher selbst. Allocation groups können praktisch als „Dateisysteme im Dateisystem“ betrachtet werden. Da Allocation groups relativ autonom sind, kann der Kernel gleichzeitig mehrere von ihnen adressieren. Hier liegt der Schlüssel zur hohen Skalierbarkeit von XFS. Das Konzept der autonomen Allocation groups kommt natürlicherweise den Anforderungen von Multiprozessorsystemen entgegen. 30 Projektarbeit Systemadministration < Journalierende Dateisysteme > Preallocation zur Vermeidung von Dateisystemfragmentation: Vor dem Schreiben der Daten in das Dateisystem reserviert XFS den benötigten Speicherplatz für eine Datei (engl. to preallocate). Somit wird die Dateisystemfragmentation erheblich reduziert. Die Leistung wird erhöht, da die Dateiinhalte nicht über das gesamte Dateisystem verteilt werden. Ein weiteres Merkmal ist die volle Unterstützung von 64-Bit Systemen, dass eine max. theoretische Dateisystemgröße von 18000 Petabyte ermöglicht. Eigenschaften Es implementiert drei Attribute: 1. Benutzer-Namensraum (user namespace): für alle Benutzer zugänglich, geschützt durch die normalen Dateimodifizierer (rwx) 2. System-Namensraum (system namespace): für privilegierte Benutzer zugänglich 3. Sicherheits-Namensraum (security namespace): wird von gesicherten Modulen verwendet -> SELinux 3.7 JFS Das Journaled File System (JFS) wurde im Jahr 2000 von IBM für ihr eigenes Betriebssystem OS/2 entwickelt, um in Hochverfügbarkeits-Server-Umgebungen einen großen Durchsatz von Daten zu gewährleisten speziell bei Dateiservern. Als volles 64-Bit-Dateisystem unterstützt JFS große Dateien und Partitionen (LFS oder Large File Support), was ein weiterer Pluspunkt für den Einsatz in ServerUmgebungen ist. Das journaling Dateisystem steht mittlerweile unter der freien GPLLizenz und wurde im Jahr 2002 von IBM ausdrücklich für das Betriebssystem Linux freigegeben und darin integriert. Es ist aber auch für AIX verfügbar. Ein genauerer Blick auf JFS zeigt, warum dieses Dateisystem möglicherweise eine gute Wahl für Ihren Linux-Server darstellt: Vorteile: Effizientes Journaling JFS folgt wie ReiserFS einem „metadata only“-Ansatz. Anstelle einer ausführlichen Überprüfung werden lediglich Metadatenänderungen überprüft, die durch kürzliche Dateisystemaktivitäten hervorgerufen wurden. Dies spart enorm viel Zeit bei der Wiederherstellung. Zeitgleiche Aktivitäten, die mehrere Protokolleinträge erfordern, können in einem Gruppen-Commit zusammengefasst werden, wobei der Leistungsverlust des Dateisystems durch mehrfachen Schreibvorgang stark verringert wird. 31 Projektarbeit Systemadministration < Journalierende Dateisysteme > Effiziente Verzeichnisverwaltung JFS hält an unterschiedlichen Verzeichnisstrukturen fest. Bei kleinen Verzeichnissen erlaubt es die direkte Speicherung des Verzeichnisinhaltes in seinem Inode. Für größere Verzeichnisse werden Binärbäume verwendet, welche die Verzeichnisverwaltung erheblich erleichtern. Bessere Speichernutzung durch dynamische Vergabe der Inodes JFS weist Inode-Speicher dynamisch zu und stellt ihn bei Nichtbedarf wieder zur Verfügung. Dadurch wird die maximale Anzahl von Dateien oder Verzeichnissen Ihres Dateisystems nicht limitiert wie z.B. bei ext2. Ab welchen Distributionen JFS in Linux unterstützt wird: ab Distribution Version Debian GNU/Linux 3.0 Gentoo Linux 1.4 Knoppix Linux 3.1 Mandrake Linux 8.1 Red Hat Linux 7.3 Slackware Linux 8.1 SuSE Linux 7.3 Turbolinux 7.0 United Linux 1.0 Nachteile: Der Hauptnachteil ist das JFS bis jetzt noch nicht so stabil ist. JFS hat keine Quota und auch keine ACL`s. 32 Projektarbeit Systemadministration < Journalierende Dateisysteme > 4. Konkrete Anwendung 4.1 Unterschiede der Implementierungen Dateisystem-Features Ext2 Max. Dateisystemgröße Blockgröße 1 KB - 4 KB Max. Dateigröße Ext3 JFS ReiserFS 16 TB 32 PB 1 EB Reiser 4 Veritas 18 EB 1KB – 4 KB 512 B – 4 KB 4 KB – 64 KB *2 2 TB 4 PB Journaling Daten/Metadaten - / - / Journal-Replay Kernel/Userspace - / - / Journal intern/extern - / 9 EB - / - / - / 16 TB 16 TB - / / - / HFS+ 512 B – 4 KB 32 KB 1 EB - / XFS / - / - / / ACL / - *1 - Erweiterte Attribute Quota - *3 Online Resize - Defrag - Dump/Restore - - - - - - zur Info die Reihenfolge: Kilo-, Mega-, Giga-, Terra-, Peta-, Exa-Byte 1) zusätzliche Software erforderlich 2) Linux-Kernel unterstützt nur Größen = 4 KB 3) Kernel Patch vorhanden 33 Projektarbeit Systemadministration < Journalierende Dateisysteme > 4.2 ext3 verwenden Formatieren von ext3-Dateisystemen mit mkfs Sobald optional die Partitionen auf dem Laufwerk mit Hilfe eines Partitionierungsprogramms wie zum Beispiel fdisk erstellt wurden, verwendet man mkfs um auf jeder Partition ein Dateisystem zu erstellen. Dafür muss man als root angemeldet sein, und Folgendes eingeben: /sbin/mkfs -t ext3 /dev/hdaX hda steht für das Laufwerk und X für die Partitionsnummer. Konvertieren in ein ext3-Dateisystem Das Programm tune2fs kann ein Journal zu einem vorhandenen ext2-Dateisystem hinzugefügen, ohne die bereits auf der Partition vorhandenen Daten zu ändern. Wenn das Dateisystem zum Zeitpunkt der Umstellung bereits gemountet ist, wird das Journal als Datei .journal im root-Verzeichnis des Dateisystems angezeigt. Ist das System nicht gemountet, ist das Journal ausgeblendet und wird im Dateisystem nicht angezeigt. Melden Sie sich zum Konvertieren eines ext2-Dateisystems in ein ext3 als Root an, und geben Sie Folgendes ein: /sbin/tune2fs -j /dev/hdaX Ersetzen Sie im obigen Befehl hda durch den Buchstaben des Laufwerks und X durch die Partitionsnummer. Stellen Sie anschließend sicher, den Partitionstyp in /etc/fstab von ext2 in ext3 zu ändern. Wenn Sie das root-Dateisystem umstellen, müssen Sie ein initrd-Image (oder RAMDisk) zum Booten verwenden. Führen Sie zum Erstellen das Programm mkinitrd aus. Weitere Informationen zum Verwenden des Befehls mkinitrd erhalten Sie, wenn Sie man mkinitrd eingeben. Stellen Sie zudem sicher, dass die LILO- oder GRUB-Konfiguration initrd lädt. Wenn das Ausführen dieser Änderung fehlschlägt, bootet das System nach wie vor, aber das root-Dateisystem wird als ext2 und nicht als ext3 gemountet. 34 Projektarbeit Systemadministration < Journalierende Dateisysteme > Wiederherstellen eines ext2-Dateisystems Manchmal ist es praktisch, alte ex2 Dienstprogramme zu benutzen. In diesem Fall kann es notwendig sein, ein Dateisystem zeitweise erneut in ext2 zu konvertieren. Um eine Partition wiederherzustellen, muss man die Partition zuerst unmounten. Hierfür gibt man als root folgendes ein: umount /dev/hdaX hda steht für das Laufwerk und X für die Partitionsnummer. Anschließend wird der Dateisystemtyp in ext2 umgeändert, indem man Folgendes eingibt: /sbin/tune2fs -O ^has_journal /dev/hda1 Partition auf Fehler prüfen: /sbin/e2fsck -y /dev/hda1 Mounten der Partition als ext2-Dateisystem: mount -t ext2 /dev/hda1 /mount/point /mount/point steht für den Mount-Point der Partition Nun muss nur noch die Datei .journal auf root-Ebene der Partition entfernt werden. Dazu muss man in das Verzeichnis wechseln, in der sie gemountet ist, und Folgendes eingeben: rm -f .journal Die alte ext3-Partiton ist nun eine ext2-Partition. 35 Projektarbeit Systemadministration < Journalierende Dateisysteme > 5. Fazit In naher Zukunft wird sicherlich das Reiser4 Filesystem dominieren, da es trotz (noch) geringen Features schon an die Zuverlässigkeit von ext3 heranreicht, und gleichermaßen in vielen Bereichen performanter ist, wie einige Benchmarks belegen. Die Entwicklung neuer Dateisysteme ist aber anhand der vielen Umsetzungsmöglichkeiten sehr wahrscheinlich. Da das Dateisystem ein autarkes System ist, das vom Betriebsystem lediglich beansprucht wird, kann nahezu jede Idee verwirklicht werden. Die Entwicklung neuer Dateisysteme ist aber anhand der vielen Umsetzungsmöglichkeiten sehr wahrscheinlich. 36 Projektarbeit Systemadministration < Journalierende Dateisysteme > Anhang 6. Quellangaben [ 1] Betriebssysteme II Skript Bücher: [ 2] Linux Magazin Internetadressen: [ 3] http://www.google.de [ 4] http://www.linux-mag.com/2000-08/journaling_01.html [ 5] http://www.bfad.de/newsletter/pdf/Journaling%20Filesystem.pdf [ 6] http://www.fh-wedel.de/%7Esi/seminare/ws01/Ausarbeitung/3.journalfs/index.html [ 7] http://www.zdv.uni-mainz.de/JoguBits/15/file.html [ 8] http://puggy.symonds.net/~rajesh/howto/ext3/ext3-2.html [ 9] http://www.wikipedia.org [10] http://www.sgi.com [11] http://www.namesys.com [12] http://www-124.ibm.com/developerworks/oss/jfs/ [13] http://www.ntfs.com [14] http://www.tfh-berlin.de/~s17048/bs/ntfs/index.htm [15] http://www.netzwelt.d [16] http://backupbook.com [17] http://developer.apple.com [18] http://www.bulma.net [19] http://www.veritas.com 37
