|
|
| Zeile 78: |
Zeile 78: |
| </noinclude> | | </noinclude> |
|
| |
|
| == Beschreibung ==
| |
| Viertee [[extended filesystem]], das für den [[Linux (Kernel)|Linux]]-Kernel entwickelt wurde
| |
| * Es ist der Nachfolger von [[ext3]] und wie dieses ein [[Journaling-Dateisystem]]
| |
| * Anders als bei ext3 ist das Journaling jedoch auch abschaltbar
| |
|
| |
| ; Geschichte
| |
| ext4 wurde 2006 von [[Andrew Morton (Programmierer)|Andrew Morton]] vorgestellt
| |
| * Ab der Version 2.6.19 war eine vorläufige Testversion offizieller Bestandteil des Linux-Kernels
| |
| <ref>[https://www.heise.de/newsticker/meldung/Linux-Dateisystem-ext4-im-Kernel-2-6-19-170659.html Linux-Dateisystem ext4 im Kernel 2.6.19] auf [[heise.de]], 12. Oktober 2006</ref> Mit dem Erscheinen von Linux 2.6.28 am 24. Dezember 2008 verließ ext4 das Haupt­entwicklungs­stadium<ref>[https://www.heise.de/newsticker/meldung/Linux-Kernel-2-6-28-erschienen-192271.html Linux-Kernel 2.6.28 erschienen] auf heise open, 25. Dezember 2008</ref> und gilt als stabil
| |
| * In Linux 4.3 wurde der Code des nativen Treibers für ext3 endgültig entfernt
| |
| * Der ext4-Treiber unterstützt zukünftig weiterhin ext3
| |
|
| |
| == Technische Eigenschaften ==
| |
| ''ext4'' benutzt 48 [[Bit]] große Blocknummern (ext3 hatte 32 Bit) und unterstützt so [[Partition (Datenträger)|Partitionen]] oder {{lang|en|[[Volume (Datenspeicher)|Volumes]]}}, die bis zu 1 [[Yobibyte|YiB]] groß sind ({{lang|en|Volumes}} größer als 16 [[Tebibyte|TiB]] erst ab [[e2fsprogs]] Version 1.42 vom 29
| |
| * November 2011), im Gegensatz zu [[ext3]], das nur 32 [[Tebibyte|TiB]] zulässt (abhängig von der Größe einer [[Speicherseite]] in der jeweiligen Maschinenarchitektur, bei [[IA-32]] zum Beispiel sind nur maximal 2<sup>32</sup> · 4 [[Kibibyte|KiB]] = 16 TiB möglich)
| |
| * Auch kann die Adressierung von Dateien über ''Extents'' erfolgen, wobei Speichereinheiten zu einem zusammenhängenden Block zusammengefasst werden
| |
| * Dies führt zu einer Reduzierung des Zusatzaufwands ([[Random-Access Memory|RAM]], [[Eingabe und Ausgabe|E/A]]-Zugriffe und [[Transaktion (Informatik)|Transaktionen]]) für große Dateien, weil nur die Nummer des ersten Blocks und deren Anzahl gespeichert werden muss (und nicht jeder Block einzeln) und kann die Leistung im Betrieb steigern
| |
|
| |
| Seit Veröffentlichung im Kernel 2.6.19 sind folgende Verbesserungen implementiert worden:
| |
|
| |
| * ab Kernel 2.6.23: mehr als 32.000 [[Verzeichnisstruktur|Unterverzeichnisse]] (Verzeichnisse: <code>dir_nlink</code>, Dateien: <code>large_dir</code>)
| |
| * ab Kernel 2.6.25: maximale Dateigröße so groß wie das gesamte Dateisystem (<code>huge_file</code>)
| |
| * ab Kernel 2.6.28: ext4 gilt als stabil
| |
| * ab Kernel 2.6.33: [[Trim (Befehl)|TRIM]]-Unterstützung (u. a
| |
| * Parameter <code>discard</code> beim [[Mounten|Einhängen]])
| |
| * ab Kernel 3.0: multiple mount protection (<code>mmp</code>)
| |
| * ab Kernel 3.2: clustered block allocation (<code>bigalloc</code>)
| |
| * ab Kernel 3.6: quota inodes in superblock (<code>quota</code>)
| |
| * ab Kernel 3.8: data stored in inode and extended attribute area (<code>inline_data</code>)
| |
| * ab Kernel 3.16: more extreme version of sparse_super (<code>sparse_super2</code>)
| |
| * ab Kernel 3.18: metadata checksumming (<code>metadata_csum</code>)
| |
| * ab Kernel 4.1: support for file-system level encryption (<code>encrypt</code>)
| |
| * ab Kernel 4.4: store the metadata checksum seed in the superblock (<code>metadata_csum_seed</code>)
| |
| * ab Kernel 4.5: project quota (<code>project</code>)
| |
| * ab Kernel 4.13: Maximale Anzahl und Größe von erweiterten Attributen pro Datei erhöht (<code>ea_inode</code>)
| |
| * ab Kernel 4.13: Maximale Anzahl von Dateien per Verzeichnis erhöht (<code>large_dir</code>)
| |
| * ab Kernel 5.2: [[Case sensitivity]] kann nun optional ausgeschaltet werden (<code>casefold</code>)
| |
| * ab Kernel 5.4: Unterstützung von mit ''verity'' geschützten Dateien (<code>verity</code>)
| |
| * ab Kernel 5.5: Unterstützung von als ''stable'' markierten ''inode'' Nummern und ''UUIDs'' (<code>stable_inodes</code>)
| |
|
| |
| Jede dieser Verbesserungen in einer neuen ext4-Version im Linux-Kernel bringt es mit sich, dass damit formatierte {{lang|en|Volumes}}, z. B
| |
| * auf (Wechsel-)datenträgern, auf einem anderen System mit älterer Version des Kernels nicht gelesen werden können,
| |
|
| |
| == Weitere Verbesserungen gegenüber [[ext3]]/[[ext2]] ==
| |
|
| |
| ; Extents
| |
| : Die wichtigste Neuerung in ext4
| |
| * Andere Dateisysteme wie z. B. [[Journaled File System|JFS]] oder [[XFS (Dateisystem)|XFS]] bieten diese Funktion schon lange
| |
| * Es bringt Geschwindigkeitsvorteile bei der Verwaltung großer Dateien und beugt der Fragmentierung vor.
| |
| :Funktionsspezifische [[mount (Unix)|mount]]-Optionen: extent. Diese Option ist nicht in der [[Manpage]] gelistet, da sie standardmäßig genutzt wird, wenn eine entsprechende ext4-Partition damit eingerichtet wurde oder eine bestehende ext3-Partition zu einer ext4-Partition mit der <code>tune2fs</code> Option <code>-O extent</code> konvertiert wurde
| |
|
| |
| ; Verbesserte [[Zeitstempel]]
| |
| : ext4 bietet Zeitstempel auf [[Nanosekunde]]n-Basis. Des Weiteren Unterstützung für Datei-Erzeugt-Datumsstempel (crtime)
| |
|
| |
| ; Online-[[Defragmentierung]]
| |
| : Defragmentierung, während die Partition eingehängt ist
| |
| * Funktion derzeit noch nicht fertiggestellt.
| |
|
| |
| ; Journal mit [[Prüfsumme]]nunterstützung
| |
| : Diese Funktion ist abwärtskompatibel zu älteren Kernelversionen und wird von diesen ignoriert
| |
| : Funktionsspezifische mount-Optionen: journal_checksum
| |
|
| |
| ; Mehrfache Voraballokation von Dateiblöcken und Inodes
| |
| : Resultiert in effizienteren Schreibvorgängen.
| |
| : Funktionsspezifische mount-Optionen: nomballoc, mballoc (beide nicht in man-pages gelistet), oldalloc, orlov (default)
| |
|
| |
| ; Zeitverzögerte [[Allokation (Informatik)|Allokation]] von Dateiblöcken und Inodes
| |
| : Derzeit nur im „data=writeback“-Journaling-Modus, spätere Versionen sollen auch den „data=ordered“-Modus unterstützen
| |
| * Resultiert in weniger CPU-Last und weniger Fragmentierung.
| |
| : Funktionsspezifische mount-Optionen: nodelalloc, delalloc
| |
|
| |
| ; [[Trim (Befehl)|TRIM]]-Unterstützung
| |
| : Seit Kernel 2.6.33 kann über die Mountoption discard/nodiscard festgelegt werden, ob ext4 das Freiwerden von Speicherbereichen per TRIM-Befehl an das eingehängte Gerät meldet; unterstützt wird dies von [[Solid-State-Drive|SSDs]] und dem [[Device Mapper]] (bei „thin provisioning“).
| |
|
| |
| Bei bestehenden ext3-Partitionen können einige der ext4-Features ohne [[Formatierung|Neuformatierung]] aktiviert werden.<ref>Thorsten Leemhuis: ''[https://www.heise.de/ct/artikel/Die-wichtigsten-Neuerungen-von-Linux-2-6-19-222007.html Drei Dateisysteme dazu]'' auf heise open, 30
| |
| * November 2006</ref>
| |
| ext2- und ext3-Partitionen können [[Mounten|eingehängt]] werden, als wären sie ext4-Partitionen
| |
| * Daraus ergeben sich durch Optimierung im ext4-Treiber bereits kleine Leistungsgewinne
| |
|
| |
| == Transparente Verschlüsselung ==
| |
| Seit Kernel 4.1 unterstützt ext4 Verschlüsselung
| |
| * Diese wurde zunächst von Google entwickelt welche über Hooks in Dateisystemen genutzt werden kann
| |
| * Neben ext4 haben derzeit [[F2FS]] und [[UBIFS]] Unterstützung für fscrypt implementiert. Das Keyhandling wird über den Kernelkeyring gemanagt
| |
|
| |
| Mit e4crypt existiert eine Referenzimplementation für ein Userspace-Tool zum Anlegen von Schlüsseln und Aktivieren der Verschlüsselung für Verzeichnisse
| |
| * Eine alternative Implementation sind die Tools fscryptctl und fscrypt.
| |
|
| |
| Voraussetzungen
| |
|
| |
| * Blocksize des ext4-Dateisystems muss zur Pagesize des Systems passen
| |
| * Kernel ab 4.1 notwendig
| |
|
| |
| Eigenschaften
| |
| * Transparente Verschlüsselung
| |
| * D. h
| |
| * kein extra Softwarelayer wird auf das Dateisystem aufgesetzt wie z. B
| |
| * bei ecryptfs
| |
| * Es lassen sich einzelne Ordner oder das ganze Dateisystem verschlüsseln
| |
| * Keyhandling über Keyring des Kernels
| |
| * Verschlüsselung erfolgt Ordnerweise: Es wird ein leeres Verzeichnis erstellt und diesem anschließend eine Policy (ein Key) vergeben
| |
| * Danach kann man in dieses Verzeichnis Dateien kopieren und Ordner anlegen, die in Folge alle verschlüsselt sind
| |
| * Ein verschlüsseltes Verzeichnis kann nur verschlüsselte Dateien enthalten
| |
| * Verschlüsselung kann bei Erstellung des ext4-Dateisystems oder nachträglich aktiviert werden
| |
| * Salt und Passphrasenhash werden im Superblock des ext4-Dateisystems abgelegt
| |
| * Daraus wird der Key gebildet
| |
| * Es können mehrere Keys für verschiedene Verzeichnisse verwendet werden
| |
|
| |
| Nachteile
| |
| * Dateiattribute wie Datum und Größe bleiben weiter unverschlüsselt
| |
| * Lediglich der Inhalt der Datei und ihr Name werden verschlüsselt
| |
| * Das Verzeichnis '/' darf nicht verschlüsselt werden, beim Versuch dies zu tun, wird ab Kernel 4.13 eine Fehlermeldung generiert
| |
| * Unverschlüsselte Dateien können nicht nachträglich verschlüsselt werden, dazu müssen sie in einen verschlüsselten Ordner kopiert werden
| |
|
| |
| == Nachteile ==
| |
| Zeitverzögerte Allokation von Dateiblöcken und Inodes erhöht das Risiko von Datenverlust bei Abstürzen oder Stromausfall
| |
| * In Kernel Version 2.6.30 wurde dieses Problem gegenüber früheren Versionen entschärft
| |
|
| |
|
| == Siehe auch == | | == Siehe auch == |