Linux-Dateisysteme erklärt: ext4 und darüber hinaus

Heute werde ich Sie durch die Geschichte von ext4 führen, einschließlich der Unterschiede zu ext3 und anderen früheren Dateisystemen.

Die meisten modernen Linux-Distributionen verwenden standardmäßig das Dateisystem Ext4, während ältere Linux-Distributionen standardmäßig Ext3, Ext2 und – wenn man weit genug zurückgeht – Ext verwendeten.
Wenn Sie neu bei Linux oder allgemein bei Dateisystemen sind, fragen Sie sich vielleicht, was ext4 im Gegensatz zu ext3 bietet. Angesichts der Berichterstattung über alternative Dateisysteme wie btrfs, XFS und ZFS fragen Sie sich möglicherweise, ob ext4 noch aktiv weiterentwickelt wird.
Wir können nicht alles Wissenswerte über Dateisysteme in einem einzigen Artikel abdecken, aber wir werden versuchen, Ihnen einen Überblick über die Geschichte des Standarddateisystems von Linux zu geben, wo es steht und was Sie erwarten können.
Beim Schreiben dieser Übersicht habe ich mich stark an verschiedenen Artikeln zum Ext-Dateisystem und meinen eigenen Erfahrungen orientiert.

Eine kurze Geschichte von ext

MINIX-Dateisystem Vor ext wurde das MINIX-Dateisystem verwendet. Falls Sie mit der Geschichte von Linux nicht vertraut sind: MINIX war ein sehr kleines Unix-ähnliches System für den IBM PC/AT-Mikrocomputer. Andrew Tannenbaum entwickelte es zu Lehrzwecken und veröffentlichte den Quellcode (in gedruckter Form!) im Jahr 1987.

IBM PC/AT Mitte der 1980er Jahre, MBlairMartin, CC BY-SA 4.0

Obwohl Sie den Quellcode von MINIX durchsehen können, handelt es sich dabei nicht wirklich um freie Open-Source-Software (FOSS). Der Verlag von Tannebaums Buch verlangt für die Ausführung von MINIX eine Lizenzgebühr von 69 US-Dollar. Diese Gebühr ist im Buchpreis enthalten. Dennoch war es für die damalige Zeit sehr preisgünstig und die Nutzung von MINIX nahm rasch zu. Tannebaums ursprüngliche Absicht, damit Betriebssystemcodierung zu lehren, wurde damit schnell übertroffen. In den 1990er Jahren erfreuten sich MINIX-Installationen an Universitäten auf der ganzen Welt großer Beliebtheit. Zu dieser Zeit entwickelte der junge Linus Torvalds mit MINIX den ursprünglichen Linux-Kernel, der erstmals 1991 angekündigt und im Dezember 1992 unter der Open-Source-Vereinbarung GPL veröffentlicht wurde.
Aber Moment mal, das ist doch ein Artikel zum Dateisystem, oder? Ja, MINIX hatte sein eigenes Dateisystem und frühe Linux-Versionen waren davon abhängig. Wie MINIX ist das Dateisystem von Linux so klein wie ein Spielzeug – das MINIX-Dateisystem kann Dateinamen mit bis zu 14 Zeichen verarbeiten und verfügt nur über 64 MB Speicherplatz. Bis 1991 betrug die typische Festplattengröße 40–140 MB. Linux braucht eindeutig ein besseres Dateisystem.

ext

Während Linus den jungen Linux-Kernel entwickelte, arbeitete Rémy Card an der ersten Generation des Ext-Dateisystems. Das Ext-Dateisystem wurde erstmals 1992 implementiert und veröffentlicht – nur ein Jahr nach der Erstveröffentlichung von Linux! -- ext löst die schlimmsten Probleme des MINIX-Dateisystems.
ext verwendete 1992 die neue Abstraktionsschicht Virtual File System (VFS) im Linux-Kernel. Im Gegensatz zum vorherigen MINIX-Dateisystem kann ext bis zu 2 GB Speicher verwalten und Dateinamen mit 255 Zeichen verarbeiten.
Aber ext dominierte nicht lange, hauptsächlich aufgrund seiner primitiven Zeitstempel (nur ein Zeitstempel pro Datei, statt der uns heute bekannten Zeitstempel für Inode, letzten Dateizugriff und letzte Dateiänderung). Nur ein Jahr später wurde es durch ext2 ersetzt.

ext2

Rémy erkannte schnell die Einschränkungen von ext und entwickelte ein Jahr später ext2 als Ersatz. Während ext seine Wurzeln noch immer in „Spielzeug“-Betriebssystemen hat, wurde ext2 von Grund auf als kommerzielles Dateisystem entwickelt und folgt dabei den Designprinzipien des Berkeley-Dateisystems von BSD.
Ext2 bot maximale Dateigrößen im GB-Bereich und Dateisystemgrößen im TB-Bereich und festigte damit in den 1990er Jahren seinen Platz in der Liga der großen Dateisysteme. Bald fand es breite Verwendung, sowohl im Linux-Kernel als auch schließlich in MINIX, und wurde mit Modulen von Drittanbietern für MacOS und Windows verfügbar gemacht.
Es müssen jedoch noch einige Probleme gelöst werden: Das ext2-Dateisystem ist wie die meisten Dateisysteme der 1990er Jahre anfällig für katastrophale Datenbeschädigungen, wenn das System abstürzt oder die Stromversorgung unterbrochen wird, während Daten auf die Festplatte geschrieben werden. Mit der Zeit kam es auch zu erheblichen Leistungseinbußen aufgrund der Fragmentierung (eine einzelne Datei wird an mehreren Orten gespeichert, die physisch über die rotierenden Festplatten verteilt sind).
Trotz dieser Probleme wird ext2 auch heute noch in einigen Sonderfällen verwendet – am häufigsten als Dateisystemformat für tragbare USB-Laufwerke.

ext3

Im Jahr 1998, sechs Jahre nach der Einführung von ext2, gab Stephen Tweedie bekannt, dass er an der Verbesserung von ext2 arbeite. Daraus wurde ext3, das im November 2001 in der Kernelversion 2.4.15 in den Linux-Hauptkernel übernommen wurde.

Packard Bell-Computer aus der Mitte der 1990er Jahre, Spacekid, CC0

Größtenteils funktionierte ext2 recht gut mit Linux-Distributionen, aber – wie FAT, FAT32, HFS und andere Dateisysteme dieser Zeit – war es im Falle eines Stromausfalls anfällig für katastrophale Beschädigungen. Tritt beim Schreiben von Daten in das Dateisystem ein Stromausfall auf, kann es zu einem so genannten inkonsistenten Zustand kommen – also zu etwas, das halb erledigt und halb nicht erledigt ist. Dies kann zum Verlust oder zur Beschädigung einer großen Anzahl von Dateien führen, die nichts mit der gespeicherten Datei zu tun haben, oder sogar dazu, dass das gesamte Dateisystem nicht mehr gemountet werden kann.
ext3 und andere Dateisysteme aus den späten 1990er Jahren, wie etwa NTFS von Microsoft, verwenden Journaling, um dieses Problem zu lösen. Das Journal ist ein speziell zugewiesener Bereich auf der Festplatte, in dem Schreibvorgänge innerhalb einer Transaktion gespeichert werden. Wenn diese Transaktion den Schreibvorgang auf der Festplatte abschließt, werden die Daten im Journal in das Dateisystem selbst übertragen. Wenn das System abstürzt, bevor dieser Vorgang ausgeführt wird, erkennt das neu gestartete System dies als unvollständige Transaktion und führt ein Rollback aus, als hätte sie nie stattgefunden. Dies bedeutet, dass zwar immer noch Dateien verloren gehen können, die gerade bearbeitet werden, das Dateisystem selbst jedoch konsistent bleibt und alle anderen Daten sicher sind.
Im Linux-Kernel sind mithilfe des Ext3-Dateisystems drei Protokollierungsebenen implementiert: Journal, geordnet und Writeback.
Journaling ist der Modus mit dem geringsten Risiko. Dabei werden Daten und Metadaten in ein Journal geschrieben, bevor sie in das Dateisystem übertragen werden. Dadurch wird zwar gewährleistet, dass die geschriebenen Dateien mit dem gesamten Dateisystem konsistent sind, die Leistung wird dadurch jedoch erheblich reduziert.
Der sequentielle Modus ist der Standardmodus für die meisten Linux-Distributionen. Der sequentielle Modus schreibt Metadaten in ein Journal und übergibt Daten direkt an das Dateisystem. Wie der Name schon sagt, ist die Reihenfolge der Vorgänge hier festgelegt: Zuerst werden die Metadaten in das Protokoll übernommen, dann werden die Daten in das Dateisystem geschrieben und dann werden die zugehörigen Metadaten im Protokoll im Dateisystem aktualisiert. Dadurch wird sichergestellt, dass im Falle eines Absturzes die mit den unvollständigen Schreibvorgängen verknüpften Metadaten weiterhin im Journal vorhanden sind und das Dateisystem die unvollständigen Schreibtransaktionen beim Zurücksetzen des Journals bereinigen kann. Im sequentiellen Modus kann ein Systemabsturz zu Fehlern für Dateien führen, die während des Absturzes aktiv geschrieben wurden, aber das Dateisystem selbst – und Dateien, die nicht aktiv geschrieben wurden – sind garantiert sicher.
Writeback ist der dritte Modus – und der am wenigsten sichere Protokollierungsmodus. Im Write-Back-Modus werden, wie im sequentiellen Modus, Metadaten protokolliert, die Daten jedoch nicht. Anders als im sequentiellen Modus können sowohl Metadaten als auch Daten in beliebiger Reihenfolge geschrieben werden, um eine optimale Leistung zu erzielen. Dies kann die Leistung erheblich verbessern, ist jedoch weitaus weniger sicher. Obwohl der Write-Back-Modus immer noch die Sicherheit des Dateisystems selbst garantiert, können Dateien, die vor einem Absturz oder einer Beschädigung geschrieben wurden, leicht verloren gehen oder beschädigt werden.
Wie zuvor ext2 verwendet ext3 eine interne 16-Bit-Adressierung. Dies bedeutet, dass die maximale Dateigröße, die von ext3 mit einer Blockgröße von 4 KB verarbeitet werden kann, 2 TiB in einem Dateisystem mit einer maximalen Größe von 16 TiB beträgt.

ext4

Ext4 wurde 2006 von Theodore Ts'o (dem damaligen Hauptentwickler von Ext3) veröffentlicht und zwei Jahre später in der Kernelversion 2.6.28 zum Linux-Hauptprodukt hinzugefügt.
Ts'o beschreibt ext4 als eine Zwischentechnologie, die ext3 deutlich erweitert, aber weiterhin auf älterer Technologie basiert. Er sagt voraus, dass ext4 letztendlich durch ein echtes Dateisystem der nächsten Generation ersetzt wird.

Dell Precision 380-Workstation, Lance Fisher, CC BY-SA 2.0

Ext4 ist in seiner Funktionalität Ext3 sehr ähnlich, unterstützt jedoch größere Dateisysteme, ist widerstandsfähiger gegen Fragmentierung, bietet eine höhere Leistung und verfügt über bessere Zeitstempel.

ext4 gegen ext3

Es gibt einige sehr spezifische Unterschiede zwischen ext3 und ext4, auf die wir uns hier konzentrieren.
Abwärtskompatibilität
Ext4 wurde speziell entwickelt, um möglichst abwärtskompatibel mit Ext3 zu sein. Dadurch können nicht nur Ext3-Dateisysteme direkt auf Ext4 aktualisiert werden; der Ext4-Treiber kann Ext3-Dateisysteme auch automatisch im Ext3-Modus mounten, wodurch die Notwendigkeit entfällt, zwei separate Codebasen zu pflegen.

Großes Dateisystem

Das Ext3-Dateisystem verwendet 32-Bit-Adressierung, wodurch es nur Dateigrößen von 2 TiB und Dateisystemgrößen von 16 TiB unterstützt (dies setzt eine Blockgröße von 4 KiB voraus, einige Ext3-Dateisysteme verwenden kleinere Blockgrößen und sind daher noch weiter eingeschränkt).
Ext4 verwendet 48 Bit interne Adressierung und kann theoretisch Dateien mit einer Größe von bis zu 16 TiB auf dem Dateisystem zuordnen, mit Dateisystemen bis zu einer Größe von 1.000.000 TiB (1 EiB). In frühen Ext4-Implementierungen beschränkten einige Userspace-Programme die maximale Dateisystemgröße noch auf 16 TiB, seit 2011 unterstützt e2fsprogs jedoch direkt Ext4-Dateisysteme, die größer als 16 TiB sind. Beispielsweise unterstützt Red Hat Enterprise Linux vertraglich nur ext4-Dateisysteme bis zu 50 TiB und empfiehlt, dass ext4-Volumes nicht größer als 100 TiB sind.

Verbesserte Zuordnungsmethode

ext4 führt eine Reihe von Verbesserungen bei der Art und Weise durch, wie Speicherblöcke zugewiesen werden, bevor sie auf die Festplatte geschrieben werden, was die Lese- und Schreibleistung erheblich verbessern kann.

Bereichsabschnitt

Ein Extent ist eine Reihe zusammenhängender physischer Blöcke (bis zu 128 MiB, bei einer angenommenen Blockgröße von 4 KiB), die reserviert und gleichzeitig angesprochen werden können. Durch die Verwendung von Extents können Sie die Anzahl der für eine bestimmte Datei erforderlichen Inodes verringern, die Fragmentierung erheblich reduzieren und die Leistung beim Schreiben großer Dateien verbessern.

Mehrblockzuordnung

ext3 ruft den Blockallocator einmal für jeden neu zugewiesenen Block auf. Wenn mehrere Autoren den Allocator gleichzeitig öffnen, kann es leicht zu einer starken Fragmentierung kommen. Ext4 verwendet jedoch eine verzögerte Zuweisung. Dadurch kann es Schreibvorgänge zusammenfassen und bessere Entscheidungen darüber treffen, wie Blöcke für Schreibvorgänge zugewiesen werden, die noch nicht festgeschrieben wurden.

Dauerhafte Vorbelegung

Beim Vorabzuordnen von Speicherplatz für eine Datei müssen die meisten Dateisysteme beim Erstellen der Datei Nullen in die Blöcke schreiben. ext4 ermöglicht stattdessen die Verwendung von fallocate(), wodurch die Verfügbarkeit von Speicherplatz garantiert wird (und versucht wird, zusammenhängenden Speicherplatz dafür zu finden), ohne dass zuerst darauf geschrieben werden muss. Dadurch wird die Leistung beim Schreiben und späteren Lesen geschriebener Daten für Streaming- und Datenbankanwendungen erheblich verbessert.

Verzögerte Zuteilung

Dies ist eine faszinierende und kontroverse Funktion. Durch die verzögerte Zuweisung kann ext4 mit der Zuweisung der tatsächlichen Blöcke, in die die Daten geschrieben werden, warten, bis es bereit ist, die Daten auf die Festplatte zu übertragen. (Im Gegensatz dazu weist ext3 Blöcke sofort zu, auch wenn noch Daten in den Schreibcache geschrieben werden.)
Durch die Verzögerung der Blockzuweisung bei zunehmender Datenmenge im Cache kann das Dateisystem bessere Entscheidungen hinsichtlich der Blockzuweisung treffen. Dies reduziert die Fragmentierung (beim Schreiben und später beim Lesen) und verbessert die Leistung erheblich. Leider erhöht es jedoch die Wahrscheinlichkeit eines Datenverlusts bei Programmen, die die Methode fsync() nicht ausdrücklich aufgerufen haben (wenn der Programmierer sicherstellen möchte, dass die Daten vollständig auf die Festplatte geschrieben werden).
Angenommen, ein Programm schreibt eine Datei vollständig neu:

fd=open("file", O_TRUNC); write(fd, data); close(fd);

Bei älteren Dateisystemen reicht close(fd); aus, um sicherzustellen, dass der Inhalt der Datei auf die Festplatte geschrieben wird. Auch wenn Schreibvorgänge strenggenommen nicht transaktional sind, besteht ein geringes Risiko eines Datenverlusts, wenn nach dem Schließen der Datei ein Absturz auftritt.
Wenn der Schreibvorgang nicht erfolgreich ist (aufgrund eines Programmfehlers, eines Festplattenfehlers, eines Stromausfalls usw.), können sowohl in der ursprünglichen als auch in der neueren Version der Datei Daten verloren gehen oder sie können beschädigt werden. Wenn andere Prozesse während des Schreibens auf die Datei zugreifen, wird ihnen die beschädigte Version angezeigt. Wenn ein anderer Prozess die Datei geöffnet hat und nicht möchte, dass ihr Inhalt geändert wird – beispielsweise eine gemeinsam genutzte Bibliothek, die mehreren laufenden Programmen zugeordnet ist. Diese Prozesse können abstürzen.
Um diese Probleme zu vermeiden, vermeiden einige Programmierer die Verwendung von O_TRUNC vollständig. Stattdessen schreiben sie möglicherweise in eine neue Datei, schließen sie und benennen sie dann in den alten Dateinamen um:

fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");

Auf Dateisystemen ohne verzögerte Zuweisung reicht dies aus, um die oben aufgeführten potenziellen Beschädigungs- und Absturzprobleme zu vermeiden: Da rename() eine atomare Operation ist, wird sie nicht durch einen Absturz unterbrochen und laufende Programme verweisen weiterhin auf die alte Datei. Jetzt benötigt die nicht verknüpfte Version der Datei nur einen offenen Dateihandle zur Datei. Da jedoch die verzögerte Zuweisung von ext4 dazu führt, dass Schreibvorgänge verzögert und neu angeordnet werden, kann „rename("newfile", "file")“ ausgeführt werden, bevor der Inhalt von „newfile“ tatsächlich auf die Festplatte geschrieben wird. Dadurch entsteht das Problem, dass parallel erneut eine fehlerhafte Version der Datei abgerufen wird.
Um dies zu mildern, versucht der Linux-Kernel (seit Version 2.6.30), diese häufigen Codefälle zu erkennen und eine sofortige Zuweisung zu erzwingen. Dadurch wird die Möglichkeit eines Datenverlusts zwar verringert, aber nicht verhindert – und bei neuen Dateien hilft es nicht. Wenn Sie Entwickler sind, beachten Sie bitte: Die einzige Möglichkeit, sicherzustellen, dass Daten sofort auf die Festplatte geschrieben werden, besteht darin, fsync() korrekt aufzurufen.

Unbegrenzte Anzahl an Unterverzeichnissen

ext3 ist auf 32.000 Unterverzeichnisse beschränkt; ext4 erlaubt eine unbegrenzte Anzahl von Unterverzeichnissen. Ab der Kernelversion 2.6.23 verwendet ext4 HTree-Indizes, um Leistungsverluste bei einer großen Anzahl von Unterverzeichnissen zu reduzieren.

Protokollüberprüfung

Ext3 führt keine Prüfsummenprotokollierung durch, was bei Festplatten außerhalb der direkten Kontrolle des Kernels oder bei Controller-Geräten mit eigenem Cache zu Problemen führt. Wenn beim Controller oder bei Festplatten mit eigenem Cache die Reihenfolge der Schreibvorgänge durcheinander gerät, kann es sein, dass die Reihenfolge der Journaltransaktionen von ext3 gestört wird und dadurch möglicherweise Dateien beschädigt werden, die während des Absturzes (oder einige Zeit davor) geschrieben wurden.
Theoretisch kann dieses Problem durch Schreibbarrieren gelöst werden. Beim Mounten des Dateisystems legen Sie in den Mount-Optionen barrier=1 fest, und das Gerät führt fsync bis hinunter zur darunterliegenden Hardware zuverlässig aus. In der Praxis hat sich gezeigt, dass Speichergeräte und Controller Schreibbarrieren häufig nicht einhalten – was die Leistung (und die Leistungsbenchmarks im Vergleich zu Wettbewerbern) verbessert, jedoch die Wahrscheinlichkeit einer Datenbeschädigung erhöht, die verhindert werden sollte.
Durch die Prüfsummenbildung im Journal kann beim erstmaligen Einhängen eines Dateisystems nach einem Absturz festgestellt werden, dass einige seiner Einträge ungültig oder in der falschen Reihenfolge sind. Auf diese Weise werden Fehler vermieden, die zu einem Zurücksetzen teilweiser oder nicht in der richtigen Reihenfolge befindlicher Protokolleinträge und zur weiteren Beschädigung des Dateisystems führen – selbst wenn einige Speichergeräte Schreibbarrieren vortäuschen oder nicht einhalten.

Schnelle Dateisystemprüfung

Wenn fsck unter ext3 aufgerufen wird, überprüft es das gesamte Dateisystem – einschließlich gelöschter oder leerer Dateien. Im Gegensatz dazu markiert ext4 nicht zugewiesene Blöcke und Sektoren in der Inode-Tabelle, sodass fsck sie vollständig überspringen kann. Dies reduziert die zum Ausführen von fsck auf den meisten Dateisystemen benötigte Zeit erheblich und ist im Kernel 2.6.24 implementiert.

Verbesserte Zeitstempel

ext3 bietet Zeitstempel mit einer Granularität von einer Sekunde. Für die meisten Zwecke ist dies zwar ausreichend, für unternehmenskritische Anwendungen ist jedoch häufig eine strengere Zeitsteuerung erforderlich. Durch die Bereitstellung von Nanosekunden-Zeitstempeln macht ext4 es für Unternehmens-, wissenschaftliche und unternehmenskritische Anwendungen nützlich.
Das Ext3-Dateisystem bietet außerdem nicht genügend Bits, um Daten nach dem 18. Januar 2038 zu speichern. ext4 fügt hier zwei Bits hinzu und verlängert die Unix-Epoche um 408 Jahre. Wenn Sie dies im Jahr 2446 n. Chr. lesen, haben Sie wahrscheinlich bereits ein besseres Dateisystem verwendet. So kann ich nach meinem Tod ruhig schlafen, wenn Sie die Zeit noch immer seit dem 1. Januar 1970, 00:00 Uhr (UTC), messen.

Online-Defragmentierung

Weder ext2 noch ext3 unterstützen die Online-Defragmentierung direkt, d. h. die Defragmentierung des Dateisystems, während es gemountet ist. ext2 verfügt über ein integriertes Dienstprogramm namens e2defrag, das tut, was sein Name vermuten lässt – es muss offline ausgeführt werden, während das Dateisystem nicht gemountet ist. (Das ist für ein Root-Dateisystem natürlich sehr problematisch.) Bei ext3 ist die Situation sogar noch schlimmer – obwohl ext3 weniger anfällig für starke Fragmentierung ist als ext2, kann die Ausführung von e2defrag auf einem ext3-Dateisystem zu katastrophalen Beschädigungen und Datenverlusten führen.
Obwohl ext3 ursprünglich als „immun gegen Fragmentierung“ galt, zeigt die Verwendung massiv paralleler Schreibprozesse auf dieselbe Datei (wie etwa BitTorrent) deutlich, dass dies nicht ganz der Fall ist. Einige Userspace-Tricks und Workarounds wie beispielsweise Shake gehen dieses Problem auf die eine oder andere Weise an – sie sind jedoch langsamer und in vielerlei Hinsicht weniger zufriedenstellend als ein echter, dateisystembewusster Defragmentierungsprozess auf Kernelebene.
ext4 löst dieses Problem mit e4defrag, einem Online-Defragmentierungsprogramm im Kernelmodus, das das Dateisystem unterstützt und auf Block- und Extent-Ebene läuft.

Laufende ext4-Entwicklung

ext4, wie der Pestkranke in Monty Python einst sagte: „Ich bin noch nicht tot!“ Obwohl sein Hauptentwickler es nur als Notlösung auf dem Weg zu einem echten Dateisystem der nächsten Generation betrachtet, wird kein wahrscheinlicher Kandidat (aufgrund technischer oder lizenzrechtlicher Probleme) so schnell bereit sein, als Root-Dateisystem eingesetzt zu werden.
In zukünftigen Versionen von ext4 müssen noch einige wichtige Funktionen entwickelt werden, darunter Metadaten-Prüfsummen, erstklassige Quotenunterstützung und große Zuordnungsblöcke.

Metadatenprüfsumme

Da ext4 über redundante Superblöcke verfügt, kann das Dateisystem die darin enthaltenen Metadaten überprüfen und selbst feststellen, ob der primäre Superblock beschädigt ist und einen Ersatzblock verwenden muss. Es ist möglich, einen beschädigten Superblock ohne Prüfsummen wiederherzustellen – der Benutzer muss jedoch zunächst erkennen, dass der Superblock beschädigt ist, und dann versuchen, das Dateisystem mit einer anderen Methode manuell zu mounten. Da das schreibgeschützte Mounten eines Dateisystems mit einem beschädigten primären Superblock in manchen Fällen weiteren Schaden verursachen kann, den selbst ein erfahrener Benutzer nicht vermeiden kann, ist dies auch keine perfekte Lösung!
Im Vergleich zu den extrem starken Prüfsummen pro Block, die von Dateisystemen der nächsten Generation wie Btrfs oder ZFS bereitgestellt werden, sind die Metadaten-Prüfsummen von ext4 sehr schwach. Aber es ist besser als nichts. Obwohl es einfach klingt, alles zu überprüfen! -- Tatsächlich bringt die Kopplung von Prüfsummen mit einem Dateisystem einige erhebliche Herausforderungen mit sich; Einzelheiten finden Sie im Entwurfsdokument.

Erstklassige Kontingentunterstützung

Moment, Quoten? ! Wir haben diese seit dem Tag, an dem Ext2 herauskam! Ja, aber sie wurden immer erst nachträglich hinzugefügt und waren immer albern. Es lohnt sich wahrscheinlich nicht, hier ins Detail zu gehen, aber das Designdokument legt dar, wie Kontingente aus dem Benutzerbereich in den Kernel verschoben und korrekter und effizienter durchgesetzt werden.

Große Zuordnungsblöcke

Mit der Zeit werden diese lästigen Speichersysteme immer größer. Da einige SSDs bereits eine Hardwareblockgröße von 8K verwenden, wird die aktuelle Beschränkung von ext4 auf 4K-Blöcke zunehmend restriktiv. Größere Speicherblöcke können die Fragmentierung erheblich reduzieren und die Leistung verbessern, allerdings auf Kosten von mehr „Schlupfspeicher“ (dem Speicherplatz, der übrig bleibt, wenn Sie nur einen Teil eines Blocks zum Speichern einer Datei oder den letzten Block einer Datei benötigen). Eine ausführliche Anleitung finden Sie im Gestaltungsdokument.

Praktische Einschränkungen von ext4

ext4 ist ein robustes, stabiles Dateisystem. Die meisten Leute sollten es heutzutage als ihr Root-Dateisystem verwenden, aber es kann nicht alle Anforderungen erfüllen. Lassen Sie uns kurz über einige Dinge sprechen, die Sie nicht erwarten sollten – jetzt oder möglicherweise in Zukunft:

Obwohl ext4 Daten mit einer Größe von bis zu 1 EiB (entspricht 1.000.000 TiB) verarbeiten kann, sollten Sie dies wirklich nicht versuchen. Neben der Fähigkeit, sich die Adressen mehrerer Blöcke zu merken, gibt es auch Skalierungsprobleme. Und derzeit kann ext4 nicht mehr als 50–100 TiB Daten verarbeiten (und wird dies wahrscheinlich auch nie tun).

Auch Ext4 reicht nicht aus, um die Datenintegrität zu gewährleisten. Obwohl die Journalisierung damals mit Ext3 einen großen Fortschritt darstellte, wurden dadurch viele häufige Ursachen für Datenbeschädigungen nicht behoben. Wenn die Daten auf der Festplatte bereits beschädigt sind – aufgrund fehlerhafter Hardware, der Einwirkung kosmischer Strahlung (ja, wirklich) oder einfach des Datenverfalls im Laufe der Zeit –, kann ext4 diese Beschädigung nicht erkennen oder reparieren.

Basierend auf den beiden oben genannten Punkten ist ext4 lediglich ein reines Dateisystem und kein Speichervolume-Manager. Dies bedeutet, dass Sie theoretisch beschädigte Daten von ext4 wiederherstellen könnten, auch wenn Sie über mehrere Festplatten verfügen (also Parität oder Redundanz), Sie können jedoch nicht wissen, ob es hilfreich wäre, dies zu Ihrem Vorteil zu nutzen. Obwohl es theoretisch möglich ist, das Dateisystem und das Speichervolume-Verwaltungssystem auf unterschiedlichen Ebenen zu trennen, ohne die automatischen Funktionen zur Beschädigungserkennung und -behebung einzubüßen, werden aktuelle Speichersysteme nicht auf diese Weise konzipiert und es würde bei neuen Designs erhebliche Herausforderungen mit sich bringen.

Alternative Dateisysteme

Bevor wir beginnen, eine Warnung: Seien Sie sehr vorsichtig, es sind keine alternativen Dateisysteme integriert und werden als Teil des Hauptkernels direkt unterstützt!

Auch wenn ein Dateisystem sicher ist, kann die Verwendung als Root-Dateisystem sehr beunruhigend sein, wenn bei einem Kernel-Upgrade etwas schief geht. Wenn Sie keinen guten Grund haben, ein alternatives Medium zum Booten über ein Chroot zu verwenden, haben Sie Geduld mit Kernelmodulen, Grub-Konfiguration und DKMS ... entfernen Sie keine reservierten Root-Dateien auf einem kritischen System.

Es kann gute Gründe geben, ein Dateisystem zu verwenden, das von Ihrer Distribution nicht direkt unterstützt wird. Wenn das jedoch der Fall ist, empfehle ich Ihnen dringend, es erst zu installieren, wenn Ihr System einsatzbereit ist. (Beispielsweise verfügen Sie möglicherweise über ein ext4-Root-Dateisystem, speichern aber die meisten Ihrer Daten in einem ZFS- oder Btrfs-Pool.)

XFS

XFS hat im Mainline-Linux denselben Status wie Nicht-Ext-Dateisysteme. Es handelt sich um ein 64-Bit-Journaling-Dateisystem, das seit 2001 in den Linux-Kernel integriert ist und eine hohe Leistung für große Dateisysteme und eine hohe Parallelität (d. h. eine große Anzahl von Prozessen, die gleichzeitig in das Dateisystem schreiben) bietet.
Ab RHEL 7 ist XFS das Standarddateisystem für Red Hat Enterprise Linux. Für Privatanwender oder kleine Unternehmen weist es dennoch einige Nachteile auf. Insbesondere die Größenänderung eines vorhandenen XFS-Dateisystems ist so mühsam, dass es keinen Sinn ergibt, einfach ein neues zu erstellen und die Daten zu kopieren.
Obwohl XFS stabil und leistungsstark ist, gibt es zwischen diesem und ext4 nicht genügend anwendungsspezifische Unterschiede, um eine Verwendung an einer anderen Stelle als der Standardeinstellung (wie RHEL7) zu empfehlen, es sei denn, es löst ein spezifisches Problem mit ext4, wie etwa Dateisysteme, die größer als 50 TiB sind.
XFS ist in keiner Weise ein Dateisystem der „nächsten Generation“ im Vergleich zu ZFS, Btrfs oder sogar WAFL (einem proprietären SAN-Dateisystem). Genau wie ext4 sollte es als Übergangslösung betrachtet werden, bis eine bessere Lösung gefunden wird.

ZFS

ZFS wurde von Sun Microsystems entwickelt und ist nach dem Zettabyte (das Äquivalent von 1 Billion Gigabyte) benannt, weil es theoretisch sehr große Speichersysteme adressieren kann.
Als echtes Dateisystem der nächsten Generation bietet ZFS Volume-Verwaltung (die Möglichkeit, mehrere separate Speichergeräte in einem einzigen Dateisystem zu verwalten), kryptografische Prüfsummen auf Blockebene (wodurch Datenbeschädigungen mit extrem hoher Genauigkeit erkannt werden können), automatische Reparatur von Beschädigungen (sofern redundanter oder Paritätsspeicher verfügbar ist), schnelle asynchrone inkrementelle Replikation, Inline-Komprimierung und vieles mehr.
Aus der Sicht eines Linux-Benutzers ist die Lizenzierungsfrage das größte Problem mit ZFS. Die ZFS-Lizenz ist die CDDL, eine semi-permissive Lizenz, die mit der GPL in Konflikt steht. Es gibt viele Kontroversen über die Bedeutung der Verwendung von ZFS im Linux-Kernel. Die Argumente reichen von „es ist ein Verstoß gegen die GPL“ über „es ist ein Verstoß gegen die CDDL“ bis hin zu „es ist völlig in Ordnung, es wurde nicht vor Gericht geprüft“. Besonders bemerkenswert ist, dass Canonical den ZFS-Code seit 2016 in seinen Standardkernel integriert hat und es bisher keine rechtlichen Einwände gab.
Selbst als begeisterter ZFS-Benutzer empfehle ich zum jetzigen Zeitpunkt nicht, ZFS als Linux-Root-Dateisystem zu verwenden. Wenn Sie die Vorteile von ZFS unter Linux nutzen möchten, richten Sie ein kleines Root-Dateisystem mit ext4 ein und verwenden Sie dann ZFS für Ihren restlichen Speicher, auf dem Sie Daten, Anwendungen usw. ablegen. Behalten Sie die Root-Partition jedoch auf ext4, bis Ihre Distribution ZFS-Roots ausdrücklich unterstützt.

Btrfs

Btrfs – die Abkürzung für B-Tree Filesystem, oft „Butter“ ausgesprochen – wurde 2007 von Chris Mason veröffentlicht, als er bei Oracle war. Btrfs verfolgt größtenteils dieselben Ziele wie ZFS und bietet die Verwaltung mehrerer Geräte, Prüfsummen pro Block, asynchrone Replikation, Inline-Komprimierung und mehr.
Seit 2018 ist Btrfs relativ stabil und kann als Standarddateisystem für Einzelplatten verwendet werden, für Volume-Manager sollte man sich jedoch wahrscheinlich nicht darauf verlassen. Es weist im Vergleich zu ext4, XFS oder ZFS in vielen gängigen Anwendungsfällen erhebliche Leistungsprobleme auf und seine Funktionen der nächsten Generation – Replikation, Multi-Disk-Topologien und Snapshot-Verwaltung – können so zahlreich sein, dass die Folgen von katastrophalen Leistungseinbußen bis hin zu tatsächlichem Datenverlust reichen können.
Der weitere Status von Btrfs ist umstritten; SUSE Enterprise Linux übernahm es 2015 als Standarddateisystem, während Red Hat 2017 ankündigte, Btrfs ab RHEL 7.4 nicht mehr zu unterstützen. Es ist vielleicht erwähnenswert, dass das Produkt Btrfs-Bereitstellungen unterstützt, die als Einzelplatten-Dateisystem verwendet werden, und nicht als Multi-Disk-Volume-Manager wie in ZFS. Sogar Synology verwendet Btrfs in seinen Speichergeräten, aber es wird zur Verwaltung der Festplatten auf traditionellem Linux-Kernel-RAID (mdraid) aufgesetzt.

Nachfolgend führen wir kurz die Einführung, Funktionen und Vorteile von ext~ext4 auf:

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an