Ein tiefer Einblick in das Journaling-Dateisystem ext3 in CentOS

Gliederung

1. Protokolldateisystem

2. Vorteile von ext3

3, drei Protokollmodi von ext3

4. Wählen Sie den Protokollmodus

1. Journal-Dateisystem

Wenn der Dateiinhalt geschrieben wird, während das System läuft, werden die Metadaten der Datei (wie Berechtigungen, Besitzer, Erstellung und Zugriffszeit) normalerweise nicht geschrieben, wenn der Zeitunterschied zwischen dem Schreiben des Dateiinhalts und dem Schreiben der Dateimetadaten besteht Wenn das System abnormal heruntergefahren wird, wird das Dateisystem im Schreibvorgang abnormal entladen und das Dateisystem befindet sich in einem inkonsistenten Zustand. Beim Neustart führt Linux das Programm fsck aus, das das gesamte Dateisystem durchsucht, um sicherzustellen, dass alle Dateiblöcke korrekt zugewiesen oder verwendet werden, beschädigte Verzeichniseinträge findet und versucht, diese zu reparieren. fsck übernimmt jedoch keine Gewähr für die Behebung von Schäden. In diesem Fall füllen inkonsistente Metadaten in der Datei den Speicherplatz der verlorenen Datei und die Dateieinträge im Verzeichniseintrag gehen möglicherweise verloren, was zum Verlust der Datei führt.

Um die Inkonsistenz des Dateisystems zu minimieren und die Startzeit des Betriebssystems zu verkürzen, muss das Dateisystem Datensätze verfolgen, die Systemänderungen verursachen. Diese Datensätze werden an einem vom Dateisystem getrennten Ort gespeichert, der normalerweise aufgerufen wird Ein Holzklotz". Sobald diese Protokolldatensätze sicher geschrieben sind, kann das Protokolldateisystem sie verwenden, um die Datensätze zu bereinigen, die die Systemänderung verursacht haben, und sie in einem Satz zu organisieren, der die Dateisystemänderung verursacht hat, indem es sie in die Datenbanktransaktion einfügt und in der Datenbanktransaktion behält Der normale Betrieb gültiger Daten steht nicht im Widerspruch zur Leistung des gesamten Systems. Im Falle eines Systemabsturzes oder eines Neustarts werden die Daten anhand der in der Protokolldatei aufgezeichneten Informationen wiederhergestellt. Da es in den Logdateien regelmäßige Checkpoints gibt, sind diese meist sehr aufgeräumt. Beim Entwurf des Dateisystems werden hauptsächlich Effizienz- und Leistungsaspekte berücksichtigt.

Linux kann viele Protokolldateisysteme unterstützen, einschließlich FAT, VFAT, HPFS (OS/2), NTFS (Windows NT), UFS, XFS, JFS, ReiserFS, ext2, ext3 usw.

2. Vorteile von ext3

Warum müssen Sie von ext2 auf ext3 migrieren? Hier sind vier Hauptgründe: Verfügbarkeit, Datenintegrität, Geschwindigkeit, einfache Migration.

Verfügbarkeit

Nach einem ungewöhnlichen Absturz (Stromausfall, Systemabsturz) kann das ext2-Dateisystem nur nach Konsistenzprüfung durch e2fsck gemountet und verwendet werden. Die Zeit zum Ausführen von e2fsck hängt hauptsächlich von der Größe des ext2-Dateisystems ab. Die Überprüfung etwas größerer Dateisysteme (mehrere zehn Gigabyte) dauert lange. Wenn sich viele Dateien im Dateisystem befinden, dauert die Überprüfung länger. Die Überprüfung eines Dateisystems mit mehreren hundert Gigabyte kann eine Stunde oder länger dauern. Dies schränkt die Benutzerfreundlichkeit erheblich ein. Im Gegensatz dazu erfordert ext3 keine Überprüfung des Dateisystems, es sei denn, es liegt ein Hardwarefehler vor, selbst wenn es abnormal heruntergefahren wird. Dies liegt daran, dass Daten auf eine Weise auf die Festplatte geschrieben werden, die im gesamten Dateisystem konsistent ist. Nach einem abnormalen Herunterfahren hängt die Zeit zum Wiederherstellen eines ext3-Dateisystems nicht von der Größe des Dateisystems oder der Anzahl der Dateien ab, sondern von der Größe des „Protokolls“, das zur Aufrechterhaltung der Konsistenz erforderlich ist. Mit den Standardprotokolleinstellungen beträgt die Wiederherstellungszeit nur eine Sekunde (abhängig von der Hardwaregeschwindigkeit).

Datenintegrität

Durch die Verwendung des ext3-Dateisystems wird die Datenintegritätsleistung bei abnormalem Herunterfahren zuverlässig gewährleistet. Sie können die Art und das Niveau des Datenschutzes wählen. Sie können das Dateisystem konsistent halten, aber zulassen, dass die Daten im Dateisystem während eines abnormalen Herunterfahrens beschädigt werden. Dies kann in einigen Situationen (jedoch nicht in allen Situationen) zu Geschwindigkeitsverbesserungen führen. Sie können sich auch dafür entscheiden, die Datenzuverlässigkeit mit dem Dateisystem in Einklang zu bringen. Dies bedeutet, dass Sie nach einem Absturz keinen Datenmüll in neu geschriebenen Dateien sehen. Diese sichere Option, die die Datenintegrität im Einklang mit dem Dateisystem aufrechterhält, ist die Standardeinstellung.

Geschwindigkeit

Obwohl ext3 Daten häufiger schreibt als ext2, ist ext3 oft schneller als ext2 (hoher Datenfluss). Dies liegt daran, dass die Protokollierungsfunktion von ext3 die Rotation der Festplattenköpfe optimiert. Sie können zwischen einem von drei Protokollierungsmodi wählen, um die Geschwindigkeit zu optimieren und dabei gezielt Datenintegrität zu opfern. Der erste Modus, data=writeback, garantiert eine begrenzte Datenintegrität und ermöglicht, dass nach einem Absturz alte Daten in der Datei vorhanden bleiben. Dieser Modus kann in bestimmten Situationen die Geschwindigkeit verbessern. (In den meisten Journaling-Dateisystemen ist dieser Modus die Standardeinstellung. Dieser Modus bietet eine begrenzte Datenintegrität für das ext2-Dateisystem und dient eher dazu, eine lange Überprüfung des Dateisystems beim Systemstart zu vermeiden.) Zweitens: Dieser Modus ist data = orderd (die Standardeinstellung). ), hält die Datenzuverlässigkeit im Einklang mit dem Dateisystem; das bedeutet, dass Sie nach einem Absturz keine Junk-Daten in neu geschriebenen Dateien sehen. Der dritte Modus, data=journal, erfordert in den meisten Fällen ein größeres Journal, um eine moderate Geschwindigkeit zu gewährleisten. Außerdem dauert die Wiederherstellung nach einem Absturz länger. Bei einigen Datenbankoperationen wird es jedoch schneller sein. Unter normalen Umständen wird empfohlen, den Standardmodus zu verwenden. Wenn Sie den Modus ändern müssen, fügen Sie bitte die Option data=mode zum entsprechenden Dateisystem in der Datei /etc/fstab hinzu. Einzelheiten finden Sie im Online-Manpage-Handbuch des Mount-Befehls (execute man mount).

Einfach zu migrieren

Sie können problemlos von ext2 auf ext3 migrieren, ohne die Festplatte neu zu formatieren, und die Vorteile eines zuverlässigen Journaling-Dateisystems genießen. Ja, Sie können die Vorteile von ext3 nutzen, ohne den langen, langweiligen und möglicherweise fehleranfälligen Vorgang „Sichern, Neuformatieren, Wiederherstellen“ durchführen zu müssen. Es gibt zwei Migrationsmethoden:

Wenn Sie Ihr System aktualisieren, unterstützt Sie das Red Hat Linux-Installationsprogramm bei der Migration. Sie müssen lediglich für jedes Dateisystem auf die Schaltfläche „Auswählen“ klicken.

Verwenden Sie das Programm tune2fs, um Protokollierungsfunktionen zu einem vorhandenen ext2-Dateisystem hinzuzufügen. Wenn das Dateisystem während des Konvertierungsvorgangs gemountet wurde, erscheint die Datei „.journal“ im Stammverzeichnis; wenn das Dateisystem nicht gemountet wurde, erscheint die Datei nicht im Dateisystem. Um das Dateisystem zu konvertieren, führen Sie einfach tune2fs -j /dev/hda1 (oder einen beliebigen Gerätenamen, auf dem sich das zu konvertierende Dateisystem befindet) aus und ändern Sie ext2 in der Datei /etc/fstab in ext3. Wenn Sie Ihr eigenes Root-Dateisystem konvertieren möchten, müssen Sie zum Booten initrd verwenden. Führen Sie das Programm gemäß der manuellen Beschreibung von mkinitrd aus und vergewissern Sie sich, dass initrd in Ihre LILO- oder GRUB-Konfiguration geladen ist (wenn dies nicht gelingt, kann das System trotzdem gestartet werden, aber das Root-Dateisystem wird als ext2 statt ext3 geladen. Sie können dies mit dem Befehl cat / proc/mounts bestätigen. Einzelheiten finden Sie im Manpage-Online-Handbuch für den Befehl tune2fs (führen Sie man tune2fs aus).

3, drei Protokollmodi von ext3

Ext3 bietet mehrere Protokollierungsmodi, d. h. unabhängig davon, ob die Metadaten des Dateisystems oder die Daten des Dateisystems geändert werden (einschließlich Änderungen an der Datei selbst), das ext3-Dateisystem kann dies unterstützen. Folgendes wird aktiviert, wenn /. etc/fstab-Datei wird gebootet. Drei verschiedene Protokollmodi:

data=Tagebuchprotokollmodus

Die Protokolldatensätze umfassen alle Daten und Metadaten, die das Dateisystem verändert haben. Es ist der langsamste der drei ext3-Journaling-Modi, minimiert jedoch die Fehlerwahrscheinlichkeit. Bei Verwendung des Modus „data=journal“ muss ext3 jede Änderung zweimal in das Dateisystem und einmal in das Journal schreiben, was die Gesamtleistung des Dateisystems verringert. Alle neuen Daten werden zunächst in das Protokoll geschrieben und dann lokalisiert. Nach einem Unfall können die Protokolle wiedergegeben werden, um die Daten und Metadaten wieder in einen konsistenten Zustand zu versetzen. Da Metadaten und Datenaktualisierungen in ext3 aufgezeichnet werden, werden diese Protokolle wirksam, wenn ein System neu gestartet wird.

data=geordneter Protokollmodus (Standard)

Nur die Metadaten des geänderten Dateisystems werden aufgezeichnet und die Überlaufdateidaten müssen der Festplatte hinzugefügt werden. Dies ist der standardmäßige ext3-Protokollierungsmodus. Dieser Modus reduziert die Redundanz zwischen dem Schreiben in das Dateisystem und dem Schreiben in das Protokoll, sodass er schneller ist. Änderungen an Dateidaten werden zwar nicht im Protokoll aufgezeichnet, müssen jedoch vor der Ausführung durchgeführt werden und werden vom ext3-Daemon-Programm gesteuert Dies bedeutet, dass die Dateisystemdaten vor der Aufzeichnung der Metadaten geändert werden müssen. Dadurch wird die Leistung (Geschwindigkeit) des Systems geringfügig verringert, es kann jedoch sichergestellt werden, dass die Dateidaten im Dateisystem mit den Daten übereinstimmen entsprechendes Dateisystem.

data=Writeback-Protokollmodus

Zeichnet nur die Metadaten von Änderungen am Dateisystem auf, aber gemäß dem Standarddateisystem muss das Schreibprogramm weiterhin die Änderungen in den Dateidaten auf der Festplatte aufzeichnen, um die Dateisystemkonsistenz aufrechtzuerhalten. Dies ist der schnellste Ext3-Journaling-Modus. Da es nur Metadatenänderungen aufzeichnet und nicht auf Aktualisierungen im Zusammenhang mit Dateidaten wie Dateigröße, Verzeichnisinformationen usw. wartet, können die Aktualisierung von Dateidaten und die Aufzeichnung von Metadatenänderungen asynchron erfolgen, d. h. ext3 unterstützt asynchrone Protokolle. Der Fehler besteht darin, dass die aktualisierten Daten beim Herunterfahren des Systems inkonsistent sind, da sie nicht auf die Festplatte geschrieben werden können. Dieses Problem kann noch nicht gelöst werden.

Es gibt Unterschiede zwischen den verschiedenen Protokollmodi, aber die Einstellungsmethode ist dieselbe und praktisch. Der Protokollmodus kann mithilfe des ext3-Dateisystems angegeben werden, was beim Start durch /etc/fstab erfolgt. Wenn Sie beispielsweise den Protokollmodus „data=writeback“ auswählen, können Sie die folgenden Einstellungen vornehmen:

/dev/hda5 /opt ext3 data=writeback 1 0

Unter normalen Umständen ist der Protokollmodus „data=ordered“ der Standardmodus des ext3-Dateisystems.

Um die Protokollierungsmethode festzulegen, können Sie die folgende Methode verwenden:

1 Fügen Sie die entsprechende Zeichenfolge zum Optionsfeld von /etc/fstab hinzu, z. B. data=journal

# /dev/sda3 /var ext3 defaults,data=writeback 1 2

2 Geben Sie beim Aufrufen von mount direkt die Befehlszeilenoption -o data=journal an.

# mount -o data=journal /dev/sdb1 /mnt

Wenn wir den Protokollmodus eines bestimmten Dateisystems überprüfen möchten, wie können wir ihn über den Befehl dmesg abfragen:

# dmesg |. grep -B 1 „gemountetes Dateisystem“

kjournald beginnt. Commit-Intervall 5 Sekunden

EXT3-fs: gemountetes Dateisystem mit geordnetem Datenmodus.

--

EXT3 FS auf sda1, internes Journal

EXT3-fs: gemountetes Dateisystem mit geordnetem Datenmodus.

--

EXT3 FS auf SDB1, internes Journal

EXT3-fs: gemountetes Dateisystem mit Journaldatenmodus.

--

EXT3 FS auf SDB1, internes Journal

EXT3-fs: gemountetes Dateisystem mit Writeback-Datenmodus.

4. Wählen Sie den Protokollmodus

Geschwindigkeit

In einigen typischen Fällen kann die Verwendung der Option data=writeback die Geschwindigkeit erheblich verbessern, gleichzeitig wird jedoch der Schutz der Datenkonsistenz verringert. In diesen Fällen ist der Datenkonsistenzschutz im Wesentlichen derselbe wie für das ext2-Dateisystem, mit der Ausnahme, dass das System während des normalen Betriebs kontinuierlich die Integrität des Dateisystems aufrechterhält (dies ist der Journaling-Modus, der von anderen Journaling-Dateisystemen verwendet wird). Dazu gehören häufige gemeinsame Schreibvorgänge, aber auch das häufige Erstellen und Löschen einer großen Anzahl kleiner Dateien, beispielsweise das Versenden einer großen Anzahl kleiner E-Mail-Nachrichten. Wenn Sie von ext2 zu ext3 wechseln und feststellen, dass die Anwendungsleistung deutlich abnimmt, kann Ihnen die Option data=writeback dabei helfen, die Leistung zu verbessern. Auch wenn Sie keine teuren Maßnahmen zum Schutz der Datenkonsistenz ergreifen, können Sie dennoch die Vorteile von ext3 nutzen (das Dateisystem ist immer konsistent). Red Hat arbeitet immer noch daran, einige Aspekte der ext3-Leistung zu verbessern, sodass einige Aspekte der ext3-Leistung in Zukunft verbessert werden können. Das bedeutet auch, dass Sie, selbst wenn Sie jetzt „data=writeback“ wählen, zukünftige Versionen erneut mit dem Standardwert „data=journal“ testen müssen, um festzustellen, ob die Änderungen in der neuen Version für Ihre Arbeit relevant sind.

Datenintegrität

In den meisten Fällen schreiben Benutzer Daten an das Ende der Datei. Nur in einigen Fällen (z. B. bei Datenbanken) schreiben Benutzer Daten in die Mitte einer vorhandenen Datei. Sogar das Überschreiben einer vorhandenen Datei wird dadurch erreicht, dass die Datei zunächst abgeschnitten und dann Daten vom Ende der Datei geschrieben werden. Wenn das System im data=ordered-Modus abstürzt, während eine Datei geschrieben wird, wird der Datenblock möglicherweise teilweise überschrieben, der Schreibvorgang ist jedoch nicht abgeschlossen, sodass das System unvollständige Datenblöcke hat, die zu keiner Datei gehören. Im Modus „data=ordered“ bleiben ungeordnete Datenblöcke nach einem Absturz nur dann bestehen, wenn ein Programm während des Absturzes eine Datei neu schreibt. In diesem Fall gibt es keine absolute Garantie für die Schreibreihenfolge, es sei denn, das Programm verwendet fsync() und O_SYNC, um zu erzwingen, dass Schreibvorgänge in einer bestimmten Reihenfolge erfolgen.

Das ext3-Dateisystem beinhaltet auch, wie die Daten im Cache auf die Festplatte geleert werden. Es führt eine regelmäßige Löschung durch den kupdate-Prozess durch. Standardmäßig werden alle 5 Sekunden überprüft und fehlerhafte Daten, die länger als 30 Sekunden sind, auf die Festplatte geleert.

In Version 3.0 kann der Zweck durch Ändern von /proc/sys/vm/bdflush erreicht werden. In Version 4.0 kann dieser Zweck durch Ändern von /proc/sys/vm/dirty_writeback_centisecs und /proc/sys/vm/dirty_expire_centisecs erreicht werden.

Da der Standardmodus der geordnete Modus ist, schreibt in diesem Modus ein IO zuerst die Datendatei und dann die Protokolldatei. Wenn das System nach dem Schreiben der Datendatei und vor dem Schreiben der Protokolldatei abstürzt, geht dieser Teil der Daten verloren. Dies ist in der Datenbank absolut nicht zulässig, egal ob es sich um Oracle oder MySQL handelt. Also

Bei Datenbankschreibvorgängen wird jeder Schreibvorgang zuerst in den Seitencache geschrieben, dann wird der Kernel-Thread benachrichtigt, um die Puffer auf die Festplatte zu leeren, und dann werden die Metadaten in das Protokoll geschrieben und schließlich der erfolgreiche Schreibvorgang Wird zurückgegeben. Auf diese Weise sind Schreibvorgänge in die Datenbank offensichtlich nicht so schnell wie das Schreiben auf bloße Geräte.

Wenn Sie also Ext3 zum Ausführen der Datenbank verwenden,

stellen Sie den Protokollmodus auf den Journalmodus ein. Die Leistung sollte verbessert werden (es wurde nicht getestet, die theoretische Analyse sollte so aussehen). Denn im Journalmodus werden bei einem Schreibvorgang in der Datenbank die Daten und Dateisystemänderungen zunächst direkt in das Protokoll geschrieben (direktes Schreiben umgeht den Cache, was eine bessere Leistung bietet), dann werden die Daten in den Cache geschrieben und dann Der kupdate-Prozess aktualisiert die Daten auf der Festplatte. Im Gegensatz dazu sollte die Leistung der DB schneller sein als die des vorherigen.

Außerdem gibt es hier den Parameter sync_binlog in MySQL. Wenn dieser Parameter auf 1 gesetzt ist, bedeutet dies, dass die Binlog-Datei jedes Mal, wenn sie geschrieben wird, gleichzeitig auf die Festplatte geleert wird, genau wie beim Schreiben von E/A durch Oracle. Wenn dieser Parameter deaktiviert ist, wird er vom Betriebssystem verwaltet, d. h. er wird alle 5 Sekunden überprüft. Wenn alte Daten von vor 30 Sekunden gefunden werden, werden sie auf die Festplatte geleert. Der Parameter innodb_flush_log_at_trx_commit beinhaltet auch das Problem des Leerens der Festplatte.

Ext3 ist als erweiterte Version von ext2 nahezu identisch mit dem von ext2 verwendeten Superblock, Inode, Gruppendeskriptor und anderen Datenstrukturen, sodass ext3 mit ext2 vorwärtskompatibel ist. Ohne die Daten des ext2-Dateisystems zu sichern, können Sie Folgendes verwenden:

1

# tune2fs –j/dev/sd1

Konvertieren Sie das ext2-Dateisystem direkt in das ext3-Dateisystem, ohne die Partition auszuhängen.

Angenommen, wenn wir eine Datei bearbeiten, kommt es zu einem plötzlichen Stromausfall oder das System ist gesperrt und muss neu gestartet werden. Was sind die Folgen? Im schlimmsten Fall geht ein Teil des Dateiinhalts verloren, im schlimmsten Fall ist der gesamte Dateiinhalt durcheinander und noch schlimmer: Das Dateisystem stürzt direkt ab. Was für eine schreckliche Sache wäre das. Wenn Linux normal heruntergefahren wird, wird eine Meldung angezeigt, dass die Deinstallation des Dateisystems zu Inkonsistenzen im Dateisystem führt. Diese Inkonsistenz wird beim Mounten des Dateisystems während der Systemneustartphase entdeckt versuche es zu reparieren. Leider wird der Zeitaufwand für solche Reparaturen mit zunehmender Kapazität der Speichergeräte immer unerschwinglicher.

Das größte Merkmal von Ext3 besteht darin, dass es eine Protokollfunktion auf Basis von ext2 hinzufügt. Daher wird das ext3-Dateisystem häufig als Protokolldateisystem bezeichnet. Das Protokolldateisystem ist jedoch nicht nur ext3, sondern auch JFS, reiserFS und XFS. Sowie NTFS usw., die wir häufig unter Windows sehen.

Die Protokollierungsfunktion von Ext3 basiert hauptsächlich auf einem Zwischengerät namens „Journaling Block Device Layer“ darunter, genannt JBD (Journaling Block Device Layer, kurz JBD). JBD ist nicht Teil der Dateisystemspezifikation. Es hat nichts mit der ext3-Dateisystemspezifikation zu tun. JBD ist die Grundlage für die Implementierung der Dateisystem-Transaktionsverarbeitungsfunktion. Kurz gesagt, JBD ist darauf ausgelegt, den besonderen Zweck der Protokollierung auf jedem Blockgerät zu implementieren (je abstrakter es wird, was ist eine Transaktion? ⊙﹏⊙…)

Was Transaktionen betrifft, sind Studierende, die Erfahrung in der Datenbankentwicklung oder im Datenbetrieb und -wartung haben, auf jeden Fall damit vertraut. Wir werden uns hier weder auf Konzepte noch auf akademische Definitionen beschränken, solange jeder weiß, dass die Hauptfunktion von Transaktionen darin besteht, die Atomizität von Operationen sicherzustellen. Wie ist dieser Satz zu verstehen? Im Finanzsystem müssen beispielsweise X Yuan von Konto A auf Konto B überwiesen werden. Dieses Unternehmen muss sicherstellen, dass X Yuan erfolgreich von Konto A überwiesen und anschließend X Yuan erfolgreich zu Konto B hinzugefügt werden. Nur wenn diese beiden Vorgänge gleichzeitig erfolgreich sind, kann die Übertragung erfolgreich sein. Wenn einer der Vorgänge fehlschlägt, muss das Geschäft beendet werden. Wenn die Überweisung von X Yuan von Konto A erfolgreich ist und beim Schreiben auf Konto B ein Fehler auftritt, müssen die von Konto A überwiesenen X Yuan an Konto A zurückgegeben werden. Eine extremere Situation besteht darin, dass die Daten von Konto A aus verschiedenen Gründen zusammenbrechen. Dann muss der Transaktionsmechanismus der Datenbank sicherstellen, dass die X Yuan von Konto A nicht verloren gehen. Dies ist die Atomizität des Datenbankgeschäftsbetriebs. Im Protokolldateisystem wird die Atomizität von Dateidatenoperationen dadurch gewährleistet, dass JBD seine Protokollierungsfunktion durch „Einbinden“ der JBD-API implementiert. Obwohl die JBD-Schicht selbst nicht viel Code enthält, handelt es sich um einen sehr komplexen Softwareteil. Wir werden hier nicht darüber sprechen und bei Gelegenheit damit experimentieren. Das Protokolldateisystem muss natürlich Protokolle aufzeichnen, und Protokolle benötigen auch Speicherplatz. Daher öffnet das Protokolldateisystem einen speziellen Bereich auf dem Speichermedium speziell für die Speicherung von Protokollinformationen:

Wir verwenden ein Bild, um kurz den zugrunde liegenden Aufbau von ext3 zu beschreiben:

Das obige ist der detaillierte Inhalt vonEin tiefer Einblick in das Journaling-Dateisystem ext3 in CentOS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!