Linux-Dateisysteme verstehen:ext4 und darüber hinaus

Die meisten modernen Linux-Distributionen verwenden standardmäßig das ext4-Dateisystem, genau wie frühere Linux-Distributionen standardmäßig ext3, ext2 und – wenn Sie weit genug zurückgehen – ext.

Wenn Sie neu bei Linux – oder bei Dateisystemen – sind, fragen Sie sich vielleicht, was ext4 an den Tisch bringt, was ext3 nicht hat. Sie fragen sich vielleicht auch, ob sich ext4 überhaupt noch in der aktiven Entwicklung befindet, angesichts der Flut von Berichterstattungen über alternative Dateisysteme wie btrfs, xfs und zfs.

Weitere Linux-Ressourcen

• Spickzettel für Linux-Befehle
• Spickzettel für fortgeschrittene Linux-Befehle
• Kostenloser Online-Kurs:RHEL Technical Overview
• Spickzettel für Linux-Netzwerke
• SELinux-Spickzettel
• Spickzettel für allgemeine Linux-Befehle
• Was sind Linux-Container?
• Unsere neuesten Linux-Artikel

Wir können nicht alles über Dateisysteme in einem einzigen Artikel behandeln, aber wir werden versuchen, Sie über die Geschichte des Standarddateisystems von Linux auf den neuesten Stand zu bringen, wo es steht und worauf Sie sich freuen können.

Ich habe mich bei der Erstellung dieser Übersicht stark auf die verschiedenen Artikel von Wikipedia zu Ext-Dateisystemen, die Wiki-Einträge von Kernel.org zu Ext4 und meine eigenen Erfahrungen gestützt.

Eine kurze Geschichte von ext

MINIX-Dateisystem

Bevor es ext gab, gab es das MINIX-Dateisystem. Wenn Sie mit Ihrer Linux-Geschichte nicht auf dem Laufenden sind, MINIX war ein sehr kleines Unix-ähnliches Betriebssystem für IBM PC/AT-Mikrocomputer. Andrew Tannenbaum hat es für Lehrzwecke entwickelt und seinen Quellcode (in gedruckter Form!) 1987 veröffentlicht.

Obwohl Sie die Quelle von MINIX lesen konnten, handelte es sich nicht wirklich um kostenlose Open-Source-Software (FOSS). Die Herausgeber von Tannebaums Buch verlangten für den Betrieb von MINIX eine Lizenzgebühr von 69 $, die in den Kosten des Buches enthalten war. Trotzdem war dies für die damalige Zeit unglaublich kostengünstig, und die Akzeptanz von MINIX nahm schnell zu und übertraf bald Tannenbaums ursprüngliche Absicht, es einfach zu verwenden, um die Codierung von Betriebssystemen zu lehren. In den 1990er Jahren konnte man MINIX-Installationen an Universitäten weltweit erfolgreich finden – und ein junger Linus Torvalds verwendete MINIX, um den ursprünglichen Linux-Kernel zu entwickeln, der erstmals 1991 angekündigt und im Dezember 1992 unter der GPL veröffentlicht wurde.

Aber warten Sie, das ist ein Dateisystem Artikel, oder? Ja, und MINIX hatte sein eigenes Dateisystem, auf das sich auch frühe Versionen von Linux stützten. Wie MINIX könnte es lieblos als „Spielzeug“-Beispiel seiner Art bezeichnet werden – das MINIX-Dateisystem konnte nur Dateinamen mit bis zu 14 Zeichen verarbeiten und nur 64 MB Speicher adressieren. 1991 war die typische Festplatte bereits 40-140 MB groß. Linux brauchte eindeutig ein besseres Dateisystem!

ext

Während Linus den jungen Linux-Kernel hackte, arbeitete Rémy Card am ersten Ext-Dateisystem. Erstmals 1992 implementiert – nur ein Jahr nach der ersten Ankündigung von Linux selbst! – löste ext die schlimmsten Probleme des MINIX-Dateisystems.

Die Erweiterung von 1992 verwendete die neue Abstraktionsschicht des virtuellen Dateisystems (VFS) im Linux-Kernel. Im Gegensatz zum MINIX-Dateisystem davor konnte ext bis zu 2 GB Speicherplatz adressieren und Dateinamen mit 255 Zeichen verarbeiten.

Aber ext hatte keine lange Herrschaft, vor allem wegen seines primitiven Zeitstempels (nur ein Zeitstempel pro Datei, anstatt der drei separaten Stempel für die Inode-Erstellung, den Dateizugriff und die Dateiänderung, mit denen wir heute vertraut sind). Nur ein Jahr später aß ext2 sein Mittagessen.

ext2

Rémy erkannte ziemlich schnell die Grenzen von ext, da er ext2 ein Jahr später als dessen Ersatz entwarf. Während ext seine Wurzeln noch in "Spielzeug"-Betriebssystemen hatte, wurde ext2 von Anfang an als kommerzielles Dateisystem entwickelt, nach den gleichen Prinzipien wie das Berkeley Fast File System von BSD.

Ext2 bot maximale Dateigrößen im Gigabyte- und Dateisystemgrößen im Terabyte-Bereich und platzierte es in den 1990er Jahren fest in den großen Ligen. Es wurde schnell und weit verbreitet, sowohl im Linux-Kernel und schließlich in MINIX, als auch durch Module von Drittanbietern, die es für MacOS und Windows verfügbar machten.

Es gab jedoch noch Probleme zu lösen:ext2-Dateisysteme waren, wie die meisten Dateisysteme der 1990er Jahre, anfällig für katastrophale Beschädigungen, wenn das System abstürzte oder die Stromversorgung verlor, während Daten auf die Festplatte geschrieben wurden. Sie litten im Laufe der Zeit auch unter erheblichen Leistungseinbußen aufgrund von Fragmentierung (Speicherung einer einzelnen Datei an mehreren Orten, physisch auf einer rotierenden Festplatte verstreut).

Trotz dieser Probleme wird ext2 auch heute noch vereinzelt verwendet – am häufigsten als Format für tragbare USB-Sticks.

ext3

1998, sechs Jahre nach der Einführung von ext2, gab Stephen Tweedie bekannt, dass er daran arbeite, es erheblich zu verbessern. Daraus wurde ext3, das im November 2001 mit Kernel-Version 2.4.15 in Mainline-Linux übernommen wurde.

Ext2 hatte sich bei den meisten Linux-Distributionen sehr gut bewährt, war aber – wie FAT, FAT32, HFS und andere Dateisysteme der damaligen Zeit – bei Stromausfall anfällig für katastrophale Beschädigungen. Wenn Sie beim Schreiben von Daten in das Dateisystem die Stromversorgung verlieren, können diese in einem sogenannten inkonsistenten Zustand verbleiben Zustand – einer, in dem die Dinge halb erledigt und halb rückgängig gemacht wurden. Dies kann zum Verlust oder zur Beschädigung großer Mengen von Dateien führen, die nichts mit der zu speichernden Datei zu tun haben, oder sogar zur Unmountbarkeit des gesamten Dateisystems.

Ext3 und andere Dateisysteme der späten 1990er, wie Microsofts NTFS, verwenden Journaling um dieses Problem zu lösen. Das Journal ist eine spezielle Zuweisung auf der Festplatte, wo Schreibvorgänge in Transaktionen gespeichert werden; Wenn die Transaktion das Schreiben auf die Festplatte beendet hat, werden ihre Daten im Journal festgeschrieben zum Dateisystem selbst. Wenn das System abstürzt Bevor diese Operation festgeschrieben wird, erkennt das neu gestartete System sie als unvollständige Transaktion und rollt sie zurück, als ob sie nie stattgefunden hätte. Das bedeutet, dass die bearbeitete Datei immer noch verloren gehen kann, aber das Dateisystem selbst bleibt konsistent und alle anderen Daten sind sicher. In der Linux-Kernel-Implementierung von ext3 sind drei Ebenen des Journalings verfügbar:journal , bestellt und Rückschreiben .

• Journal ist der Modus mit dem geringsten Risiko, bei dem sowohl Daten als auch Metadaten in das Journal geschrieben werden, bevor sie an das Dateisystem übergeben werden. Dies gewährleistet die Konsistenz der Datei, in die geschrieben wird, sowie des Dateisystems als Ganzes, kann jedoch die Leistung erheblich beeinträchtigen.
• Bestellt ist der Standardmodus in den meisten Linux-Distributionen; Der geordnete Modus schreibt Metadaten in das Journal, übergibt die Daten jedoch direkt an das Dateisystem. Wie der Name schon sagt, die Bestellung der Operationen ist hier starr:Erstens werden Metadaten an das Journal übergeben; Zweitens werden Daten in das Dateisystem geschrieben, und erst dann werden die zugehörigen Metadaten im Journal in das Dateisystem selbst übertragen. Dadurch wird sichergestellt, dass im Falle eines Absturzes die mit unvollständigen Schreibvorgängen verbundenen Metadaten immer noch im Journal sind und das Dateisystem diese unvollständigen Schreibvorgänge bereinigen kann, während das Journal zurückgesetzt wird. Im geordneten Modus kann ein Absturz zur Beschädigung der Datei oder der Dateien führen, in die während des Absturzes aktiv geschrieben wird, aber das Dateisystem selbst – und Dateien, in die nicht aktiv geschrieben wird – sind garantiert sicher.
• Zurückschreiben ist der dritte – und am wenigsten sichere – Journaling-Modus. Im Rückschreibmodus werden wie im geordneten Modus Metadaten aufgezeichnet, Daten jedoch nicht. Im Gegensatz zum geordneten Modus können Metadaten und Daten gleichermaßen in jeder beliebigen Reihenfolge geschrieben werden, die für die beste Leistung sinnvoll ist. Dies kann erhebliche Leistungssteigerungen bieten, ist aber viel unsicherer. Obwohl der Writeback-Modus immer noch eine Sicherheitsgarantie für das Dateisystem selbst bietet, werden Dateien, in die während oder geschrieben wurde vor dem Absturz anfällig für Verlust oder Beschädigung sind.

Wie zuvor ext2 verwendet ext3 die interne 16-Bit-Adressierung. Das bedeutet, dass bei einer Blockgröße von 4 KB die größte Dateigröße, die es verarbeiten kann, 2 TiB bei einer maximalen Dateisystemgröße von 16 TiB beträgt.

ext4

Theodore Ts'o (der bis dahin der Hauptentwickler von ext3 war) kündigte ext4 im Jahr 2006 an und es wurde zwei Jahre später in Kernel-Version 2.6.28 zu Mainline-Linux hinzugefügt. Ts'o bezeichnet ext4 als eine Notlösungstechnologie, die ext3 erheblich erweitert, aber immer noch auf alte Technologie angewiesen ist. Er erwartet, dass es irgendwann durch ein echtes Dateisystem der nächsten Generation ersetzt wird.

Ext4 ist funktional sehr ähnlich zu ext3, bringt aber Unterstützung für große Dateisysteme, verbesserten Widerstand gegen Fragmentierung, höhere Leistung und verbesserte Zeitstempel.

Ext4 vs. ext3

Ext3 und ext4 haben einige sehr spezifische Unterschiede, auf die ich mich hier konzentrieren werde.

Abwärtskompatibilität

Ext4 wurde speziell entwickelt, um mit ext3 so abwärtskompatibel wie möglich zu sein. Dadurch können nicht nur ext3-Dateisysteme direkt auf ext4 aktualisiert werden; es erlaubt dem ext4-Treiber auch, ext3-Dateisysteme automatisch im ext3-Modus zu mounten, was es unnötig macht, die beiden Codebasen separat zu pflegen.

Große Dateisysteme

Ext3-Dateisysteme verwendeten 32-Bit-Adressierung und beschränkten sie auf 2 TiB-Dateien und 16 TiB-Dateisysteme (unter der Annahme einer Blockgröße von 4 KiB; einige ext3-Dateisysteme verwenden kleinere Blockgrößen und sind daher noch weiter eingeschränkt).

Ext4 verwendet eine interne 48-Bit-Adressierung, wodurch es theoretisch möglich ist, Dateien mit bis zu 16 TiB auf Dateisystemen mit bis zu 1.000.000 TiB (1 EiB) zuzuweisen. Frühe Implementierungen von ext4 waren von einigen Userland-Dienstprogrammen noch auf 16 TiB-Dateisysteme beschränkt, aber seit 2011 unterstützt e2fsprogs direkt die Erstellung von>16 TiB ext4-Dateisystemen. Beispielsweise unterstützt Red Hat Enterprise Linux vertraglich ext4-Dateisysteme nur bis zu 50 TiB und empfiehlt ext4-Volumes nicht größer als 100 TiB.

Zuweisungsverbesserungen

Ext4 führt viele Verbesserungen bei der Zuweisung von Speicherblöcken ein, bevor sie auf die Festplatte geschrieben werden, was sowohl die Lese- als auch die Schreibleistung erheblich steigern kann.

Ausmaße

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

Multiblock-Zuordnung

Ext3 hat seinen Blockzuordner einmal für jeden neu zugewiesenen Block aufgerufen. Dies könnte leicht zu einer starken Fragmentierung führen, wenn mehrere Writer gleichzeitig geöffnet sind. ext4 verwendet jedoch eine verzögerte Zuweisung, die es ihm ermöglicht, Schreibvorgänge zusammenzuführen und bessere Entscheidungen darüber zu treffen, wie Blöcke für noch nicht festgeschriebene Schreibvorgänge zugewiesen werden sollen.

Permanente Vorabzuweisung

Bei der Vorabzuweisung von Speicherplatz für eine Datei müssen die meisten Dateisysteme bei der Erstellung Nullen in die Blöcke für diese Datei schreiben. Ext4 erlaubt die Verwendung von fallocate() stattdessen, was die Verfügbarkeit des Speicherplatzes garantiert (und versucht, zusammenhängenden Speicherplatz dafür zu finden), ohne zuerst darauf schreiben zu müssen. Dies erhöht die Leistung sowohl beim Schreiben als auch beim zukünftigen Lesen der geschriebenen Daten für Streaming- und Datenbankanwendungen erheblich.

Verzögerte Zuordnung

Dies ist eine zähe und umstrittene Funktion. Die verzögerte Zuweisung ermöglicht es ext4, mit der Zuweisung der tatsächlichen Blöcke zu warten, in die es Daten schreiben wird, bis es bereit ist, diese Daten auf die Festplatte zu übertragen. (Im Gegensatz dazu würde ext3 Blöcke sofort zuweisen, sogar während die Daten noch in einen Schreibcache flossen.)

Das Verzögern der Zuweisung von Blöcken, wenn sich Daten im Cache ansammeln, ermöglicht es dem Dateisystem, vernünftigere Entscheidungen über die Zuweisung dieser Blöcke zu treffen, die Fragmentierung (Schreiben und später Lesen) zu reduzieren und die Leistung erheblich zu steigern. Leider nimmt er zu das Potenzial für Datenverlust in Programmen, die nicht speziell für den Aufruf von fsync() geschrieben wurden wenn der Programmierer sicherstellen möchte, dass die Daten vollständig auf die Festplatte geschrieben wurden.

Nehmen wir an, ein Programm schreibt eine Datei komplett neu:

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

Bei älteren Dateisystemen close(fd); reicht aus, um sicherzustellen, dass der Inhalt von file wird auf die Festplatte gespült. Obwohl der Schreibvorgang streng genommen nicht transaktional ist, besteht nur ein sehr geringes Risiko, dass die Daten verloren gehen, wenn nach ein Absturz auftritt die Datei wird geschlossen.

Wenn das Schreiben nicht gelingt (aufgrund von Fehlern im Programm, Fehlern auf der Festplatte, Stromausfall usw.), werden sowohl die Originalversion als auch Die neuere Version der Datei kann verloren gehen oder beschädigt werden. Wenn andere Prozesse auf die Datei zugreifen, während sie geschrieben wird, sehen sie eine beschädigte Version. Und wenn andere Prozesse die Datei geöffnet haben und nicht erwarten, dass sich ihr Inhalt ändert – z. B. eine gemeinsam genutzte Bibliothek, die mehreren laufenden Programmen zugeordnet ist – können sie abstürzen.

Um diese Probleme zu vermeiden, vermeiden einige Programmierer die Verwendung von O_TRUNC überhaupt. Stattdessen könnten sie in eine neue Datei schreiben, sie schließen und sie dann über der alten umbenennen:

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

Unter Dateisystemen ohne verzögerte Zuordnung, dies reicht aus, um die oben beschriebenen potenziellen Beschädigungs- und Absturzprobleme zu vermeiden:Da rename() ist eine atomare Operation, sie wird nicht durch einen Absturz unterbrochen; und laufende Programme verweisen weiterhin auf die alte, jetzt nicht mehr verknüpfte Version von file solange sie ein offenes Dateihandle haben. Da die verzögerte Zuweisung von ext4 jedoch dazu führen kann, dass Schreibvorgänge verzögert und neu geordnet werden, muss rename("newfile","file") kann vorher durchgeführt werden den Inhalt von newfile werden tatsächlich auf die Festplatte geschrieben, was das Problem eröffnet, dass parallele Prozesse fehlerhafte Versionen von file erhalten alles noch einmal.

Um dies abzumildern, versucht der Linux-Kernel (seit Version 2.6.30), diese häufigen Codefälle zu erkennen und die sofortige Zuordnung der betreffenden Dateien zu erzwingen. Dies reduziert, verhindert aber nicht das Potenzial für Datenverlust – und es hilft überhaupt nicht bei neuen Dateien. Wenn Sie ein Entwickler sind, beachten Sie bitte:Die nur Um sicherzustellen, dass Daten sofort auf die Festplatte geschrieben werden, rufen Sie fsync() auf angemessen.

Unbegrenzte Unterverzeichnisse

Ext3 war auf insgesamt 32.000 Unterverzeichnisse beschränkt; ext4 erlaubt eine unbegrenzte Anzahl. Beginnend mit Kernel 2.6.23 verwendet ext4 HTree-Indizes, um Leistungsverluste bei einer großen Anzahl von Unterverzeichnissen zu mildern.

Journal-Prüfsummenbildung

Ext3 überprüfte seine Journale nicht, was Probleme für Platten- oder Controller-Geräte mit eigenen Caches darstellte, die außerhalb der direkten Kontrolle des Kernels liegen. Wenn ein Controller oder eine Festplatte mit eigenem Cache nicht in der richtigen Reihenfolge schreibt, könnte dies die Journaling-Transaktionsreihenfolge von ext3 unterbrechen und möglicherweise Dateien beschädigen, in die während (oder für einige Zeit vor) einem Absturz geschrieben wird.

Theoretisch wird dieses Problem durch die Verwendung von Schreibbarrieren gelöst – beim Mounten des Dateisystems setzen Sie barrier=1 in den Mount-Optionen, und das Gerät wird dann fsync() berücksichtigen Ruft den ganzen Weg hinunter zum Metall. In der Praxis hat sich herausgestellt, dass Speichergeräte und Controller dies häufig nicht tun Beachten Sie Schreibbarrieren – verbessern Sie die Leistung (und Benchmarks, wenn sie mit ihren Konkurrenten verglichen werden), eröffnen Sie jedoch die Möglichkeit einer Datenbeschädigung, die hätte verhindert werden sollen.

Durch die Prüfsumme des Journals kann das Dateisystem erkennen, dass einige seiner Einträge beim ersten Einhängen nach einem Absturz ungültig oder in der falschen Reihenfolge sind. Dadurch wird der Fehler vermieden, teilweise oder falsch geordnete Journaleinträge rückgängig zu machen und das Dateisystem weiter zu beschädigen – selbst wenn die Speichergeräte lügen und Barrieren nicht einhalten.

Schnelle Dateisystemprüfungen

Unter ext3 musste das gesamte Dateisystem – einschließlich gelöschter und leerer Dateien – überprüft werden, wenn fsck wird aufgerufen. Im Gegensatz dazu markiert ext4 nicht zugeordnete Blöcke und Abschnitte der Inode-Tabelle als solche, was fsck ermöglicht sie ganz zu überspringen. Dadurch wird die Zeit zum Ausführen von fsck erheblich verkürzt auf den meisten Dateisystemen und ist seit Kernel 2.6.24 implementiert.

Verbesserte Zeitstempel

Ext3 bot Zeitstempel mit einer Granularität von einer Sekunde an. Während es für die meisten Anwendungen ausreicht, suchen unternehmenskritische Anwendungen häufig nach einer viel, viel strengeren Zeitkontrolle. Ext4 stellt sich diesen Unternehmens-, wissenschaftlichen und geschäftskritischen Anwendungen zur Verfügung, indem es Zeitstempel im Nanosekundenbereich anbietet.

Ext3-Dateisysteme lieferten auch nicht genügend Bits, um Daten über den 18. Januar 2038 hinaus zu speichern. Ext4 fügt hier zwei zusätzliche Bits hinzu und verlängert die Unix-Epoche um weitere 408 Jahre. Wenn Sie dies im Jahr 2446 n. Chr. Lesen, sind Sie hoffentlich bereits auf ein besseres Dateisystem umgestiegen – aber es wird mich posthum sehr, sehr glücklich machen, wenn Sie immer noch die Zeit seit UTC 00:00, 1. Januar 1970, messen.

Online-Defragmentierung

Weder ext2 noch ext3 unterstützten direkt die Online-Defragmentierung – das heißt, das Defragmentieren des Dateisystems während des Mountens. Ext2 hatte ein mitgeliefertes Dienstprogramm, e2defrag , das tat, was der Name andeutet – aber es musste offline ausgeführt werden, während das Dateisystem nicht gemountet war. (Dies ist natürlich besonders problematisch für ein Root-Dateisystem.) Die Situation war in ext3 noch schlimmer – obwohl ext3 viel weniger wahrscheinlich unter schwerer Fragmentierung litt als ext2, das e2defrag ausführte gegen ein ext3-Dateisystem kann zu katastrophaler Beschädigung und Datenverlust führen.

Obwohl ext3 ursprünglich als „nicht von Fragmentierung betroffen“ galt, machten Prozesse, die massiv parallele Schreibprozesse in dieselbe Datei verwenden (z. B. BitTorrent), deutlich, dass dies nicht vollständig der Fall war. Mehrere Userspace-Hacks und Problemumgehungen, wie z. B. Shake, haben dies auf die eine oder andere Weise angegangen – aber sie waren langsamer und in verschiedener Hinsicht weniger zufriedenstellend als ein echter, dateisystembewusster Defragmentierungsprozess auf Kernel-Ebene.

Ext4 geht dieses Problem direkt mit e4defrag an , ein Online-Dienstprogramm zur Defragmentierung auf Block- und Extent-Ebene im Kernel-Modus, mit Dateisystemerkennung.

Laufende ext4-Entwicklung

Ext4 ist, wie die Monty Python Pestopfer sagte einmal:"Noch nicht ganz tot!" Obwohl sein Hauptentwickler es nur als Notlösung auf dem Weg zu einem wirklichen Dateisystem der nächsten Generation betrachtet, wird keiner der wahrscheinlichen Kandidaten (aufgrund technischer oder lizenzrechtlicher Probleme) für einige Zeit bereit sein, als Root-Dateisystem eingesetzt zu werden.

In zukünftigen Versionen von ext4 werden noch einige Schlüsselfunktionen entwickelt, darunter Metadaten-Prüfsummen, erstklassige Quota-Unterstützung und große Zuordnungsblöcke.

Metadaten-Prüfsummenbildung

Da ext4 über redundante Superblöcke verfügt, bietet die Prüfsummenbildung der darin enthaltenen Metadaten dem Dateisystem eine Möglichkeit, selbst herauszufinden, ob der primäre Superblock beschädigt ist und einen alternativen verwenden muss. Es ist möglich, sich von einem beschädigten Superblock ohne Prüfsummen zu erholen – aber der Benutzer müsste zuerst erkennen, dass es war beschädigt, und versuchen Sie dann, das Dateisystem manuell mit einer Alternative einzuhängen. Da das Mounten eines Dateisystems Read-Write mit einem korrupten primären Superblock in manchen Fällen weiteren Schaden anrichten kann, ist dies selbst für einen ausreichend erfahrenen Benutzer keine ausreichende Lösung!

Verglichen mit der extrem robusten Prüfsummenbildung pro Block, die von Dateisystemen der nächsten Generation wie btrfs oder zfs angeboten wird, ist die Metadaten-Prüfsummenbildung von ext4 eine ziemlich schwache Funktion. Aber es ist viel besser als nichts.

Obwohl es sich wie ein Kinderspiel anhört – ja, Prüfsummen ALLES! – gibt es einige erhebliche Herausforderungen, Prüfsummen nachträglich in ein Dateisystem zu schrauben; Einzelheiten finden Sie im Designdokument.

Erstklassige Quotenunterstützung

Warte, Quoten?! Die haben wir seit den ext2-Tagen! Ja, aber sie waren immer ein nachträglicher Einfall, und sie waren immer irgendwie scheiße. Es lohnt sich wahrscheinlich nicht, hier auf die haarigen Details einzugehen, aber das Designdokument legt dar, wie Kontingente aus dem Userspace in den Kernel verschoben und korrekter und performanter durchgesetzt werden.

Große Zuordnungsblöcke

Mit der Zeit werden diese lästigen Speichersysteme immer größer und größer. Da einige Solid-State-Laufwerke bereits 8K-Hardware-Blockgrößen verwenden, wird die derzeitige Beschränkung von ext4 auf 4K-Blöcke immer einschränkender. Größere Speicherblöcke können die Fragmentierung verringern und die Leistung erheblich steigern, auf Kosten von mehr „Schlupf“-Speicherplatz (der Speicherplatz, der übrig bleibt, wenn Sie nur einen Teil eines Blocks zum Speichern einer Datei oder das letzte Stück einer Datei benötigen).

Sie können die haarigen Details im Designdokument einsehen.

Praktische Einschränkungen von ext4

Ext4 ist ein robustes, stabiles Dateisystem, und es ist das, was die meisten Leute 2018 wahrscheinlich als Root-Dateisystem verwenden sollten. Aber es kann nicht mit allem umgehen. Lassen Sie uns kurz über einige der Dinge sprechen, die Sie nicht tun sollten von ext4 erwarten – jetzt oder wahrscheinlich in der Zukunft.

Obwohl ext4 bis zu 1 EiB – das entspricht 1.000.000 TiB – an Daten adressieren kann, haben Sie wirklich, wirklich sollte es nicht versuchen. Es gibt Skalierungsprobleme, die darüber hinausgehen, sich nur die Adressen von viel mehr Blöcken zu merken, und ext4 skaliert jetzt (und wird wahrscheinlich nie) sehr gut über 50-100 TiB an Daten hinaus.

Ext4 tut auch nicht genug, um die Integrität Ihrer Daten zu gewährleisten. So groß der Fortschritt wie das Journaling in den ext3-Tagen war, es deckt nicht viele der häufigsten Ursachen für Datenkorruption ab. Wenn Daten beschädigt werden, während sie sich bereits auf der Festplatte befinden – durch fehlerhafte Hardware, Auswirkungen kosmischer Strahlung (ja, wirklich) oder einfache Verschlechterung der Daten im Laufe der Zeit – hat ext4 keine Möglichkeit, eine solche Beschädigung zu erkennen oder zu reparieren.

Aufbauend auf den letzten beiden Punkten ist ext4 nur ein reines Dateisystem , und kein Storage Volume Manager. Das bedeutet, dass selbst wenn Sie mehrere Festplatten haben – und daher Parität oder Redundanz, von denen Sie theoretisch beschädigte Daten wiederherstellen könnten – ext4 keine Möglichkeit hat, dies zu wissen oder zu Ihrem Vorteil zu nutzen. Während es theoretisch möglich ist Ein Dateisystem und ein Speichervolumenverwaltungssystem in getrennte Schichten zu trennen, ohne die Funktionen zur automatischen Beschädigungserkennung und -reparatur zu verlieren, ist nicht die Art, wie aktuelle Speichersysteme entworfen werden, und es würde erhebliche Herausforderungen für neue Designs darstellen.

Alternative Dateisysteme

Bevor wir anfangen, ein Wort der Warnung:Seien Sie sehr Seien Sie vorsichtig mit alternativen Dateisystemen, die nicht in integriert und direkt unterstützt sind als Teil des Mainline-Kernels Ihrer Distribution!

Auch wenn ein Dateisystem sicher ist , kann die Verwendung als Root-Dateisystem absolut beängstigend sein, wenn während eines Kernel-Upgrades ein Schluckauf auftritt. Wenn Sie nicht extrem sind fühlen Sie sich wohl mit der Idee, von alternativen Medien zu booten und manuell und geduldig in Kernel-Modulen, Grub-Konfigurationen und DKMS von einer Chroot aus zu stöbern ... gehen Sie nicht aus der Reservierung mit dem Root-Dateisystem auf einem System heraus, das Ihnen wichtig ist. P>

Es kann durchaus gute Gründe geben, ein Dateisystem zu verwenden, das Ihre Distribution nicht direkt unterstützt – aber wenn Sie dies tun, empfehle ich Ihnen dringend, es nachdem zu mounten Das System ist betriebsbereit und einsatzbereit. (Beispielsweise könnten Sie ein ext4-Root-Dateisystem haben, aber die meisten Ihrer Daten in einem zfs- oder btrfs-Pool speichern.)

XFS

XFS ist ungefähr so ​​​​mainline wie ein nicht-ext-Dateisystem unter Linux. Es ist ein 64-Bit-Journaling-Dateisystem, das seit 2001 in den Linux-Kernel integriert ist und eine hohe Leistung für große Dateisysteme und ein hohes Maß an Parallelität bietet (d. h. eine wirklich große Anzahl von Prozessen, die alle gleichzeitig in das Dateisystem schreiben). P>

XFS wurde ab RHEL 7 zum Standarddateisystem für Red Hat Enterprise Linux. Es hat immer noch ein paar Nachteile für Privatanwender oder kleine Unternehmen – vor allem ist es eine echte Qual, die Größe eines bestehenden XFS-Dateisystems so weit zu ändern, dass es normalerweise mehr macht sinnvoll, ein weiteres zu erstellen und Ihre Daten zu kopieren.

Obwohl XFS stabil und leistungsfähig ist, gibt es keinen ausreichend konkreten Endnutzungsunterschied zwischen ihm und ext4, um seine Verwendung überall dort zu empfehlen, wo es nicht der Standard ist (z. B. RHEL7), es sei denn Es behandelt ein spezifisches Problem, das Sie mit ext4 haben, wie z. B. Dateisysteme mit einer Kapazität von>50 TiB.

XFS ist in keiner Weise ein Dateisystem der „nächsten Generation“ wie ZFS, btrfs oder sogar WAFL (ein proprietäres SAN-Dateisystem). Wie ext4 sollte es höchstwahrscheinlich als Notlösung auf dem Weg zu etwas Besserem betrachtet werden.

ZFS

ZFS wurde von Sun Microsystems entwickelt und nach dem Zettabyte benannt, das 1 Billion Gigabyte entspricht, da es theoretisch so große Speichersysteme ansprechen könnte.

Als echtes Dateisystem der nächsten Generation bietet ZFS Volume-Management (die Fähigkeit, mehrere einzelne Speichergeräte in einem einzigen Dateisystem zu adressieren), kryptografische Prüfsummenbildung auf Blockebene (ermöglicht die Erkennung von Datenbeschädigungen mit einer extrem hohen Genauigkeitsrate), automatische Reparatur von Beschädigungen (wobei redundanter oder Paritätsspeicher ist verfügbar), schnelle asynchrone inkrementelle Replikation, Inline-Komprimierung und mehr. Vieles mehr.

Das größte Problem mit ZFS aus Sicht eines Linux-Benutzers ist die Lizenzierung. ZFS wurde von CDDL lizenziert, einer semi-permissiven Lizenz, die im Widerspruch zur GPL steht. Es gibt viele Kontroversen über die Auswirkungen der Verwendung von ZFS mit dem Linux-Kernel, wobei die Meinungen von „es ist eine GPL-Verletzung“ über „es ist eine CDDL-Verletzung“ bis zu „es ist vollkommen in Ordnung, es wurde nur nicht vor Gericht getestet“ reichen. " Am bemerkenswertesten ist, dass Canonical seit 2016 ohne rechtliche Anfechtung ZFS-Code inline in seine Standardkernel integriert hat.

Zu diesem Zeitpunkt sogar als sehr Da ich selbst ein begeisterter ZFS-Benutzer bin, würde ich ZFS nicht als Root-Linux-Dateisystem empfehlen. Wenn Sie die Vorteile von ZFS unter Linux nutzen möchten, richten Sie dann ein kleines Root-Dateisystem auf ext4 ein Legen Sie ZFS auf Ihren verbleibenden Speicher und legen Sie Daten, Anwendungen, was immer Sie möchten, darauf – aber behalten Sie Root auf ext4, bis Ihre Verteilung explizit erfolgt unterstützt eine zfs-Root.

btrfs

Btrfs – kurz für B-Tree Filesystem und normalerweise „Butter“ ausgesprochen – wurde 2007 von Chris Mason während seiner Zeit bei Oracle angekündigt. Btrfs verfolgt fast die gleichen Ziele wie ZFS und bietet die Verwaltung mehrerer Geräte, Prüfsummenbildung pro Block, asynchrone Replikation, Inline-Komprimierung und mehr.

Ab 2018 ist btrfs einigermaßen stabil und als Standard-Einzelplatten-Dateisystem verwendbar, sollte aber wahrscheinlich nicht als Volume-Manager verwendet werden. Es leidet in vielen gängigen Anwendungsfällen unter erheblichen Leistungsproblemen im Vergleich zu ext4, XFS oder ZFS, und seine Funktionen der nächsten Generation – Replikation, Topologien mit mehreren Festplatten und Snapshot-Verwaltung – können ziemlich fehlerhaft sein, mit Ergebnissen, die von einer katastrophal reduzierten Leistung reichen zum tatsächlichen Datenverlust.

Der aktuelle Status von btrfs ist umstritten; SUSE Enterprise Linux hat es 2015 als Standarddateisystem eingeführt, während Red Hat angekündigt hat, dass es btrfs ab RHEL 7.4 im Jahr 2017 nicht mehr unterstützen würde. nicht als Volume-Manager für mehrere Festplatten a la ZFS – sogar Synology, das Btrfs auf seinen Speichergeräten verwendet, es aber auf herkömmliches Linux-Kernel-RAID (mdraid) legt, um die Festplatten zu verwalten.