Bei Dateisystemen gibt es keinen Stillstand. Im Hinblick auf ihre immense Verantwortung geschehen aber alle Fortschritte zäh, konservativ und abseits der öffentlichen Wahrnehmung. Ubuntus aktuelle Parteinahme für ZFS sorgt für frische Diskussion.

Seit vielen Jahren gilt das Dateisystem Ext4 als Standard auf dem Linux-Desktop, zumeist auch auf Servern. Eindeutige Plädoyers für andere Dateisysteme wie etwa beim NAS-System Freenas für ZFS blieben rar. 2017 schlug sich Open Suse Leap auf die Seite von BTRFS, und neuerdings hat Ubuntu ZFS in die Desktop-Installation integriert (wenn auch optional). Wir nehmen dies zum Anlass für einen Heftschwerpunkt zum Thema „Dateisysteme“. Dieser erste Beitrag soll die Bedeutung und prinzipielle Funktionsweise von Dateisystemen skizzieren, die wichtigsten kurz charakterisieren und die erweiterten Fähigkeiten von Dateisystemen diskutieren. Dies führt dann zwangslos zu Fragen, für welche Szenarien sich welche Dateisysteme am besten eignen und ob der Linux-Desktop tatsächlich eine Abkehr vom bisherigen Ext4-Standard benötigt.

Die nachfolgenden vier Artikel führen dann in den praktischen PC-Alltag und zeigen Basiskonfiguration und Tuning-Tipps für die Linux-Dateisysteme Ext4, ZFS, BTRFS und für Windows-Alternativen für den Datenaustausch.

1. Dateisysteme: Die sichtbare Spitze

Am Linux-Desktop zeigen sich Dateisysteme nur an zwei Stellen deutlich: bei der (manuellen) Installation und in der Laufwerksverwaltung. Die Installation bietet die Formatierung mit Ext2/3/4, XFS, JFS, BTRFS, eventuell ZFS, die Laufwerksverwaltung hat in der Regel zusätzlich NTFS und FAT32, exFAT im Angebot. Inaktive (ausgegraute) Linux-Dateisysteme lassen sich durch Nachinstallationen passender Pakete aktivieren.

Die Aktion, ein Laufwerk oder einen Teil dessen (Partition) mit einem Dateisystem zu versehen, nennt sich bekanntlich „Formatieren“. Optionales Partitionieren (Aufteilen) eines Laufwerks ist einer Formatierung vorgeschaltet. Dort und in der daraus resultierenden Partitionstabelle geht es darum, ein Laufwerk aus organisatorischen Gründen in mehrere Bereiche aufzuteilen (Partitionen). Sobald eine Partition anschließend durch ein Dateisystem formatiert wird, erhält die Partition in der Partitionstabelle eine knappe Kennziffer, um welches Dateisystem es sich handelt.

Die sichtbare Spitze des Eisbergs „Dateisystem“ wird wesentlich größer, sobald die zugehörigen Terminaltools zum Einsatz kommen. Erst diese zeigen die Komplexität und die Tatsache, dass ein Formatieren mit grafischen Werkzeugen für zahlreiche Parameter einfach bewährte Kompromisswerte setzt. Ein besonders wichtiger Parameter ist die Block- oder Clustergröße, die standardmäßig 512 Bytes, heute meist 4 KB beträgt.

Wichtig und sichtbar für den Anwender sind ferner Standardverzeichnisse eines Dateisystems. Diese sind allerdings bloße Namen, Konvention und Tradition, und vom eigentlichen Handwerk des Dateisystems Lichtjahre entfernt.

2. Dateisystem-Pflicht: Die Übersetzungsleistung

Dateisysteme kennen Pflicht und Kür (dazu später). Unabdingbare Pflicht für jedes Dateisystem ist es, angeforderte Dateien zu finden und bereitzustellen. Die Tatsache, dass sich Dateien über hierarchische Pfade, über Namen, Extensionen oder Datumsangaben aufrufen oder filtern lassen, erfordert erheblichen Verwaltungsaufwand. Der Controller der Hardware (Festplatte, SSD) kann jede Einheit (Sektor, Block) in Milli- oder Mikrosekunden ansteuern. Aber er braucht die exakte Kennziffer der gewünschten Einheit: Ordner und Dateinamen sind ihm so fremd wie der Dateibegriff insgesamt. Wenn ein Laufwerk die Bits aus etlichen angeforderten Blöcken ausliefert, weiß es weder, dass es sich um eine zusammengehörige Datei handelt, noch weniger, dass diese sich in einem bestimmten Ordner befindet und einen Namen besitzt. Nebenbei: Auch die Einteilung in Partitionen ist der Hardware unbekannt. Das ist alles Aufgabe des Dateisystems.

Das Dateisystem errichtet ab Formatierung eine Dateitabelle. Jede Datei erhält dort einen Eintrag mit Metadaten wie Dateiname, Erstelldatum, Rechtemaske. Format und Umfang dieser Einträge bestimmen die maximalen Datei- und Pfadnamen, maximale Dateigrößen und die Tauglichkeit für Multiuser-Systeme mit Rechteverwaltung. Entscheidend zum Auffinden der Dateiinhalte ist der Verweis auf die Zuordnungseinheiten – Cluster oder Blöcke (Cluster ist der klarere Begriff für eine Dateisystemeinheit, weil „Block“ auch Hardware-technisch die kleinste Datenträgereinheit meint). Um die Übersetzungsarbeit für die Hardware zu vereinfachen, entsprechen diese Cluster genau oder als einfaches Vielfaches der Block- oder Sektorgröße des Datenträgers – oft vier KB, sofern der Nutzer bei der Formatierung keine andere Wahl trifft. Als Clusterzeiger in der Dateitabelle dient dann eine schlichte Ziffer für den Startcluster der Datei, ferner eine weitere Ziffer für die Anzahl der Folgecluster (da eine Datei in der Regel mehrere oder viele Cluster beansprucht).

Nehmen wir an, Sie klicken im Dateimanager auf eine Datei „Rechnung_034-2020.odt“. Woher weiß das Dateisystem, dass es den Inhalt dieser Datei etwa aus den Clustern 12057, 12058 und 12116 zu laden hat? Und woher weiß das System, welche Dateinamen es anzeigen soll, wenn Sie im Home-Verzeichnis auf „Dokumente“ klicken? Anhand der kompletten Pfadangabe beginnt die Suche immer auf der obersten Ebene der Dateitabelle. Dort findet sich der Eintrag für den ersten Ordnernamen der Pfadangabe, in dessen Inhalt geht die Suche dann weiter zum nächsten Unterordner gemäß Pfadangabe bis hinunter zur gesuchten Datei.

Noch sind wir beim Eintrag der Datei in der Dateitabelle – nicht bei der Datei selbst: Wo diese liegt, zeigen nun aber die Cluster-Verweise. Startcluster und Anzahl der Cluster können nun an die Hardware weitergegeben werden. Wenn die Datei unfragmentiert ist, also der komplette Inhalt in einer zusammenhängenden Clusterfolge abgelegt ist, genügt es, den Startcluster anzuspringen und ab dort die angegebene Anzahl von Cluster einzulesen. Bei fragmentierten Dateien folgt in der Dateitabelle ein weiterer Eintrag mit dem nächsten Startcluster und der Clusteranzahl.

3. Dateisystem-Kür: Erweiterte Eigenschaften

Die angesprochene Kernaufgabe erledigt jedes Dateisystem. Die Limits für Pfadlänge, Dateigröße und Datenträgergröße sind zum Teil pragmatisch (Pfadlänge bei NTFS, Größen bei F2FS oder Ext2/3), ohne aber bei Desktop-Systemen an ernsthafte praktische Grenzen zu stoßen. Lediglich das alte FAT32 hat mit einer maximalen Dateigröße von nur 4 GB ein Limit, das in den PC-Alltag hineinwirkt.

Was Dateisysteme neben der Pflicht der Dateibereitstellung zusätzlich leisten sollen, wird durchaus kontrovers interpretiert. Die einzelnen Eigenschaften (siehe Tabelle) lassen sich in folgende Hauptaspekte gliedern:

1. OPTIMIERTE LEISTUNG: Während einfache Dateisysteme Schreibaktionen sofort und undifferenziert einfach in die nächstmöglichen freien Cluster schreiben, gibt es eine Reihe von intelligenteren Methoden, um erstens die Zugriffe zu beschleunigen und zweitens die Fragmentierung zusammenhängender Dateien zu verringern. Allocate-on-Flush verzögert den Schreibvorgang, um den kompletten Platzbedarf einer Datei abzuwarten und dann zusammenhängend zu speichern (unfragmentiert). Extents verschlanken die Dateisystemtabelle, indem sie bei vermehrten Metadaten selbige in normale Datencluster auslagern. Permanentes Dateisystem-Caching verwendet nur ZFS mit entsprechenden RAM-Ansprüchen.

Sparse-Dateien sind eine intelligente Antwort auf Dateien ohne Inhalt: Das Dateisystem erkennt die „Leere“ und belegt keine Cluster, selbst wenn die Metadaten eine formale Dateigrößen im MB- oder GB-Bereich definieren. Trim-Support ist eine Spezialität für SSDs, um die Hardware über gelöschte und somit freigewordene Blöcke zu informieren. Eine eher marginale Eigenschaft ist Execute-in-Place, das Programmausführung direkt vom Datenträger erlaubt (ohne Kopie in den Arbeitsspeicher), aber nur für sehr speziellen Programmecode in Betracht kommt.

2. OPTIMIERTE SICHERHEIT: Das verbreitete Journaling ist sowohl eine Sicherheitsfunktion als auch eine Leistungsoptimierung: Das Journal protokolliert entweder nur die Metadaten in der Dateitabelle oder sämtliche Änderungen an Dateiinhalten (Full Journaling). Nach Absturz, Hard Reset oder Stromausfall muss das Dateisystem dann nicht komplett geprüft werden, sondern sieht im Journal alle Dateiänderungen, die nicht ordentlich abgeschlossen wurden. Einige wenige Dateisysteme führen obendrein gesonderte Change-Logs und schreiben Checksummen in die Metadaten. Copy-on-Write (CoW) bedeutet, dass geänderte Blöcke nicht an Ort und Stelle überschrieben, sondern zunächst in freie Cluster kopiert werden. Die dadurch entstehende Redundanz ist Voraussetzung für Snapshot-Sicherung (nur BTRFS und ZFS).

3. ERWEITERTE METADATEN: Alle elaborierteren Dateisysteme notieren als Metadaten deutlich mehr als die unbedingt erforderlichen Pfade, Namen und Clusterverweise. Besitz, Dateirechte, mehrere Zeitstempel und Streams als formal unstrukturierte Metadaten sind fast überall Standard. Streams eignen sich als interne Infos für Software, aber auch als Kommentarfunktion.

4. ERWEITERTE FUNKTIONEN: Besondere Attraktivität für Anwender haben native Zusatzfunktionen des Dateisystems wie Verschlüsselung und Kompression. Hier kann das ansonsten pragmatische NTFS gegenüber den Linux-Standards klar punkten. Snapshots zur Systemsicherung bieten andererseits nur die Linux-Dateisysteme BTRFS und ZFS. Diese gehen aber noch einen ganzen Schritt weiter, indem sie einen eigenen Volume-Manager zur Laufwerksverwaltung integrieren. Funktional bedeutet das, dass Größenänderungen des Dateisystems online wie offline und mit Anschluss zusätzlicher Laufwerke möglich sind.

4. Dateisysteme und ihre Performance

Zur Leistung von Dateisystemen gibt es zahlreiche Messungen, die sich aber nicht gegenseitig bestätigen. Zuverlässiges Testen der Dateisystemleistung ist heikel, weil sehr viele Faktoren mitspielen. Die Größe der Dateien ist relevant, weil Dateisysteme ihre jeweiligen Vorzüge besitzen. Noch wichtiger ist die Clustergröße, denn jedes Dateisystem ist umso schneller, je weniger Einzelblöcke es zusammensuchen muss. Ein gerechter Vergleich müsste überall dieselbe Clustergröße verwenden – soweit dies einstellbar ist. Dies wiederum kann zu Ungerechtigkeiten führen, wenn Dateisysteme intern auf ihre Standardgrößen hin optimiert sind. Für einen gerechten Vergleich müssten ferner alle Daten unfragmentiert vorliegen. Spezielle Funktionen wie Kompression müsste man von vornherein ausschalten, eventuell auch das Aufzeichnen von speziellen Metadaten – soweit dies überhaupt vorgesehen ist.

Angesichts dieser Situation ist ein objektiver Vergleichstest eine akademische Herausforderung, die wir an dieser Stelle radikal und vereinfachend abkürzen: Generell darf man von einfachen Dateisystemen wie Ext2 oder FAT32, die sich weder mit Journaling, Fehlerprüfung noch mit luxuriösen Metadaten abgeben müssen, höheren Durchsatz erwarten. Gerade auf nicht systemrelevanten Laufwerken mit Benutzerdaten ist älteres Ext2 oft die beste und schnellste Alternative, exFAT auch nicht immer verkehrt. F2FS bietet sich für USB-Sticks an. Elaborierte Dateisysteme können den zusätzlichen Verwaltungsaufwand durch optimierte Schreibverfahren und präventive Maßnahmen gegen die Fragmentierung nur teilweise kompensieren.

5. Relevante Dateisysteme

Wie viele Dateisysteme braucht Linux? Die Betriebssystem-Konkurrenz leistet sich längst nicht den Luxus so zahlreicher Entwicklungen. Der langjährige Windows-Standard NTFS ist bislang ausreichend und hat Komfortfunktionen an Bord, ähnliches gilt für APFS unter Mac OS sowie das einfachere HFS+. Für wachsende Server-Ansprüche arbeitet Microsoft an ReFS, das zwar astronomische Kapazitäten verwaltet, aber noch viele unter NTFS selbstverständliche Attribute vermissen lässt. Für das einfache Austauschformat FAT32 hat Microsoft beizeiten den Nachfolger exFAT nachgelegt, um drängende Größenlimits zu überwinden.

Unter Linux tummeln sich zahlreiche prominente, exotische und spezialisierte Dateisysteme. Die Übersichtstabelle beschränkt sich auf jene, die am Linux-Desktop in Erscheinung treten (etwa in der Laufwerksverwaltung). Da Ext4, BTRFS und ZFS nachfolgend eigene Beiträge erhalten, beschränken wir uns an dieser Stelle auf eine Kurzcharakteristik der verbleibenden Dateisysteme Ext3, Ext2, JFS, XFS und F2FS:

Ext3 und Ext2: Der wichtigste Unterschied dieser Ext-Versionen ist das mit Ext3 eingeführte Journal. Wo diese Sicherheitsfunktion keine Rolle spielt, ist Ext2 die einfachere und schlankere Wahl. Anders ausgedrückt: Wenn Journaling-Sicherheit gefragt ist (Systempartition), nimmt man besser gleich Ext4, wo nicht, genügt auch Ext2.

XFS: Das Journaling-Dateisystem wurde ursprünglich für Server-Aufgaben geschaffen. Die ehemals gelobten Geschwindigkeitsvorteile beim Umgang mit sehr großen Dateien und beim Mehrfachzugriff auf Daten dürften mittlerweile weitgehend egalisiert sein. Ein spürbarer Unterschied zu Ext4 besteht heute nicht mehr. Messbar mag XFS aber immer noch vorne liegen, da etwa Open Suse die Home-Partition standardmäßig mit XFS formatiert.

JFS: Das „Journaling File System“ ist so alt (1990 von IBM), dass es die damals noch revolutionäre Journal-Funktion zur Namensgebung verwendete. JFS ist heute eigentlich JFS2 und hat keine herausragenden Eigenschaften, aber auch keine nennenswerten Schwächen.

F2FS: Das „Flash-Friendly File System“ von Samsung ist ein Spezialist für Flash-Speicher – also für SD-Karten, SSDs und eMMC. Die begrenzte Lebensdauer von rund 10.000 Schreibzugriffe pro Speicherzelle legt es dort nahe, die Dateiinhalte turnusmäßig so umzuverteilen, dass alle Bereiche des Datenträgers in etwa gleichmäßig beansprucht werden. Für solches „Wear-Leveling“ sorgt die Hardware im Prinzip selbständig. F2FS entlastet diese Aufgabe aber dadurch, dass es die Daten für Schreibvorgänge strukturiert und zwischen Daten mit tendenziell kurzer (Benutzerdaten) und langer Lebensdauer (Dateitabelle, Betriebssystem) unterscheidet. F2FS ist in der Regel nicht vorinstalliert, kann aber mit dem Paket „f2fs-tools“ leicht nachgerüstet werden:

Der Linux-Standard Ext4

Das robuste Ext4 ist in den meisten Linux-Distributionen der Standard bei der Installation und bei der Formatierung externer Laufwerke. Die Voreinstellungen garantieren Datensicherheit, Ext4-Tools ermöglichen optionales Tuning und Dateiverschlüsselung.

Die Entwicklung von Ext („Extended Filesystem“) reicht über die Vorgänger 3 und 2 letztlich zurück bis ins Jahr 1993. Änderungen bei Ext folgten ganz konservativ den gewachsenen Standardanforderungen (etwa Journaling-Sicherheit) oder technischen Notwendigkeiten (etwa Kapazitätslimits), experimentelle Extras standen offenbar nie zur Diskussion. Version Ext4 hat mit seinen aktuellen Spezifikationen keine drohenden Limits hinsichtlich Gerätegrößen, Dateigrößen oder mangelnder Metadaten. Es darf seit mehr als 10 Jahren als Quasi-Standard auf allen Desktop- und Server-Distributionen gelten, wo ein grundsolides Dateisystem gewünscht ist – genau das: nicht weniger, nicht mehr.

Integration und Werkzeuge

Die kleine Ewigkeit als Linux-Standard hatte wenige Konsequenzen am grafischen Desktop. Zwar ist eine händische Formatierung mit

sudo mkfs.ext4 […]

nur in Sonderfällen nötig, weil Installer und Laufwerksverwaltungen Ext4 integrieren. Nennenswert darüber hinaus geht die Desktop-Integration aber nicht. Auch für Ext4 sind Interna nur über Terminalwerkzeuge zu erledigen. Alle Ext4-Tools sind im Standardpaket e2fsprogs enthalten und mit

dpkg -L e2fsprogs

leicht zu ermitteln. Neben den fundamentalen Programmen mke2fs oder gleichbedeutend mkfs.ext4 (Formatieren) und e2fsck oder gleichbedeutend fsck.ext4 (Integritätscheck) gibt es eine ganze Reihe weiterer Werkzeuge: badblocks, debugfs, dumpe2fs, e2image, e2scrub, e2undo sind allesamt forensische Tools, die im Alltag keine große Rolle spielen und typische PC-Anwender überfordern dürften. e2freefrag, e4defrag, filefrag liefern Infos zur Fragmentierung oder leisten aktive Defragmentierung (e4defrag). E4defrag kann mit Schalter „-v“ auf Einzeldateien, Verzeichnisse und Partitionen angewandt werden.

Resize2fs ist das Low-Level-Tool für Größenänderungen von Partitionen. In der Regel wird man hierfür am Desktop bevorzugt zum grafischen Gparted greifen. Für die beiden verbleibenden und interessantesten Ext-Tools – tune2fs und e4crypt – folgen konkrete Einsatzbeispiele.

Laufwerksoptionen mit tune2fs steuern

Das Werkzeug tune2fs steuert viele Dateisystemeigenschaften wie die zu schreibenden Metadaten, die Absicherung durch das Journaling oder die Häufigkeit von Integritätschecks. Selbst auf der Systempartition sind nicht immer Standards erforderlich, auf externen Datenträger noch weniger. Klar ist dennoch: Folgende Eingriffe verringern die Robustheit des Dateisystems und bleiben eine Ermessensfrage.

Ext4-Journaling abschalten: Auf externen Laufwerken mit (oft nur redundanten) Benutzerdaten ist die Absicherung durch das Journalprotokoll selten notwendig. Ohne Journaling entfallen viele Schreibaktionen, was den Datendurchsatz beschleunigt. Oft wäre dort die Wahl des Journal-freien Vorgängers Ext2 von vornherein die bessere Wahl, aber auch auf Ext4 lässt sich Journaling deaktivieren (hier für „sde1“):

sudo umount /dev/sde1

sudo tune2fs -O ^has_journal /dev/sde1

„tune2fs -O“ (Buchstabe „O“) entfernt Dateisystemattribute mit „^“, während „+“ solche hinzufügen kann. Die aktuellen Eigenschaften ermitteln Sie so:

sudo tune2fs -l /dev/sde1

Die Ausgabe wird nach obiger Aktion neben „Filesystem features“ das Attribut „has_journal“ nicht mehr anzeigen.

Ext4-Checks reduzieren: Folgender tune2fs-Befehl

sudo tune2fs -i60 -c100 /dev/sda

reduziert die Datenträgerchecks: Die langwierige Prozedur wird dann nur noch alle 60 Tage („-i60“) oder nach 100 Neustarts („-c100“) erfolgen – je nachdem, welches Ereignis früher erfüllt ist.

Reservierten root-Speicher reduzieren: Ext4 reserviert auf jeder Partition Speicherplatz für das root-Konto. Falls ein System durch eine vollgeschriebene Systempartition lahmgelegt wird, kann sich noch root anmelden. Der reservierte Platz beträgt immerhin fünf Prozent der Gesamtkapazität und lässt sich gefahrlos verringern:

sudo tune2fs -m 1 /dev/sda1

Dies reduziert die Anzahl der root-Reserve auf Partition „/dev/sda1“ auf ein Prozent. Ganz ausschalten („-m 0“) sollten Sie die Reserve aber nicht.

Ext4-Metadaten reduzieren: Ext4-formatierte Partitionen speichern bei jeder Datei mehrere Zeitangaben. Erstelldatum und Änderungsdatum werden immer eingetragen (ctime und mtime: Creation und Modification). Optional ist hingegen das Erfassen des letzten Dateizugriffs (atime: Access). Diese Information ist nur dann relevant, wenn Sie mit „find -atime“ nach Zugriffszeiten von Dateiobjekten suchen. Wenn Sie das nie tun, kann die Festplattenaktivität reduziert werden. Hier hilft ausnahmsweise nicht tune2fs, sondern nur ein Eingriff in die Datei /etc/fstab:

UUID=[…]   /  ext4   noatime   0   2

Wenn in der Optionen-Spalte bereits Einträge stehen, setzen Sie „,noatime“ an deren Ende (mit Trennkomma). Der Vollständigkeit halber: Es gibt auch noch die Option „nodiratime“, die bei Verzeichnissen darauf verzichtet, die Zugriffszeit zu vermerken. Wenn Sie die Aktivität der Festplatte reduzieren möchten, ist „noatime“ die weitreichendere Maßnahme.

Verschlüsselung mit Ext4

Ext4 hat durch Google transparente Verschlüsselung erhalten, die Google im Hinblick auf Android-Geräte entwickelt hat. Die Leistung der Ext4-Verschlüsselung ist mit Cryptsetup/LUKS vergleichbar oder sogar besser, außerdem fordert Ext4-Verschlüsselung keine Neuformatierung. Trotzdem muss man diese Option unter Linux noch deutlich kritisch beurteilen – nach dem Motto: Es funktioniert im Prinzip. Die nachfolgend beschriebene Aktion beschränkt sich auf das einfache, aber realistische Szenario, dass das Verzeichnis eines USB-Datenträgers nur auf genau einem PC gelesen werden darf.

Da eine engere Desktop- oder Dateimanager-Integration fehlt, müssen im Terminal die beiden Tools tune2fs und e4crypt zusammenarbeiten. Folgendes Kommando

sudo tune2fs -O +encrypt /dev/sdc1

aktiviert zunächst die Verschlüsselung für Partition /dev/sdc1 (auf bereits vorhandene Daten hat diese Aktion keine Auswirkung). Danach benötigt die Verschlüsselung einen Ext4-Schlüssel:

e4crypt add_key

Das Passwort wird nur einmal abgefragt und hat keine Komplexitätsanforderungen. Dieser Schlüssel wird im Schlüsselbund des gerade angemeldeten Benutzers gespeichert. Der Befehl

keyctl show

gibt Einblick in den Schlüsselbund (eventuell muss dafür das kleine Paket „keyutils“ nachinstalliert werden) und zeigt den neuen Ext4-Schlüssel als „logon: ext4:…“. Die nach „ext4:“ folgende Hexadezimal-ID brauchen Sie zur Verschlüsselung des Verzeichnisses (Beispiel):

e4crypt set_policy [Hex-ID] /media/lw/Privat

Ab sofort werden alle neuen Dateien im Verzeichnis „Privat“ automatisch auf Dateisystem-Ebene verschlüsselt gespeichert und transparent wieder entschlüsselt. Das funktioniert, solange der Ext4-Schlüssel im Schlüsselbund gespeichert ist, also bis zur nächsten Anmeldung am System. Ohne Schlüssel bleibt der Datenträger zwar insgesamt lesbar, aber der Ordner „Privat“ zeigt nur Zeichensalat – auch bei den Dateinamen. Für erneuten Zugriff auf die Daten genügt nach dem Einhängen des Ext4-Datenträgers die erneute Eingabe dieses Befehls:

e4crypt add_key

Das Tool fragt das Passwort ab und lädt bei korrekter Eingabe den Ext4-Schlüssel in den Schlüsselbund. Das Verzeichnis und die enthaltenen Dateien sind dann sofort wieder lesbar. Das Systemkonto, das diese Aktion ausführt, spielt keine Rolle. Wer auf dem betreffenden Rechner das Kennwort weiß, hat Zugriff auf das verschlüsselte Verzeichnis des Ext4-Datenträgers.

Das Dateisystem ZFS

Das ursprünglich für Sun Solaris entwickelte ZFS gilt als „last word in filesystems“. Es geht über die engere Definition eines „Dateisystem“ weit hinaus, kennt keine Limits, besitzt alle Funktionen und Metadaten und integriert einen Volume Manager.

Eine gerechte Bewertung von ZFS ist nicht einfach: Metadaten, Besitzrecht, ACLs, Streams, Zeitstempel, Checksummen, Hardlinks, Softlinks, Quotas, Journaling, Caching? Alles drin – und viel mehr: Das Dateisystem hat nach heutigem Ermessen keine Größen- oder Mengenbegrenzungen. Dazu arbeitet es als Volume Manager zum Zusammenlegen von Festplattenpools, verkleinert/vergrößert den Pool online durch Hotplug oder Entnahme von Datenträgern. Der integrierte RAID-Z-Controller ermöglicht ausfallsichere Mehrfachspeicherung. Automatische und manuelle Snapshots sorgen für Systemsicherheit (neben der automatischen Fehlerkorrektur und Journaling). Datenkomprimierung, Verschlüsselung und Netzfreigaben erledigt ZFS noch nebenbei.

ZFS im Desktop-Anflug (Ubuntu)? Kaum je zuvor ist auf dem PC-Desktop etwas so krass Überdimensioniertes gelandet wie dieses Dateisystem. Das ist kein SUV oder Pick-Up, der nicht in die Garage passt: Hier landet ein Chinook-Transporthubschrauber im Schrebergarten. „Viel zu groß“ ist aber nur das eine Problem, fast noch gewichtiger ist die Tatsache, dass für dieses Flugobjekt kein Führerschein A bis D ausreicht. Wer die Piloten-Ausbildung machen will, muss ein Semester einplanen.

ZFS: Werkzeuge und Grundlagen

ZFS ist nicht im Linux-Kernel integriert, weil Linus Torvalds dies – auch, aber nicht nur – aus lizenzrechtlichen Bedenken ablehnt. Die einzige Linux-Distribution, die optionale ZFS-Unterstützung direkt mitbringt, ist Ubuntu 20.04/20.10, sofern diese Option bei der Ubuntu-Installation gewählt wurde. Überall sonst – und auch unter Ubuntu ohne ZFS-Installation – lässt sich das ZFS-Dateisystem mit diesen beiden Paketen

sudo apt install zfsutils-linux zfs-fuse

nachrüsten. Eine Integration in grafische Werkzeuge ist dadurch aber nicht gegeben, ZFS erfordert grundsätzlich Terminalarbeit. Die in den genannten Paketen enthaltenen Terminalprogramme sind mit zfs, zpool und zfs-fuse überschaubar, hinzu kommen noch eher periphere Tools zdb (Debugger) und zstreamdump (Output-Filter für „zfs send“). Die geringe Toolanzahl kann aber nicht lange darüber hinwegtäuschen, wie komplex ZFS ist: Die Manpages für die beiden Werkzeuge zfs und zpool könnten mit etwas Kommentierung dieses Magazin füllen.

ZFS fordert eine großzügige Cache-Verwaltung, deren RAM-Verbrauch von der Festplattenkapazität abhängt: Einige Hundert MB gehen verwaltungstechnisch grundsätzlich weg, ferner pro TB Plattenkapazität etwa ein GB RAM. Ein Desktop-Rechner mit einer 4-TB-Platte muss also etwa 4 GB RAM für ZFS abzweigen. Außerdem laufen für ZFS mindestens vier Systemdienste, der wichtigste heißt „zfs-zed“.

Wer sich bei einer Ubuntu-Installation für ZFS entscheidet, erlebt dies erst einmal als unkomfortable Zunahme an Komplexität: Laufwerkstools wie Gparted oder Gnome-Disks zeigen die rpool-Partitionen von ZFS zwar an, können sie aber nicht bearbeiten. Terminaltools wie mount, lsblk oder df werden durch die komplexe ZFS-Partitionierung durchweg unübersichtlicher.

Für produktive Nutzung sind „zfs“ und „zpool“ zuständig. Ersteres verantwortet die Eigenschaften des Dateisystems, zweiteres ist für die Verwaltung der Datenträger zuständig, die bei ZFS immer als „Pool“ organisiert sind, selbst wenn nur ein Datenträger vorliegt. Der Befehl

zpool list

zeigt die aktuellen ZFS-Datenträger des Pools an, Basisbefehle wie „zpool create“ oder „zpool add“ formatieren Datenträger mit ZFS oder fügen sie einem bestehendem Pool hinzu.

Einem Pool untergeordnet sind ZFS-Datasets, die keineswegs einem kompletten Datenträger entsprechen müssen. In Datasets werden Standardpfade und Snapshots als je einzelnes Dateisystem verwalten, wie folgender zfs-Befehl zeigt:

zfs list

Er bringt die Mount-Übersicht und informiert über den Belegungszustand. Eine detaillierte Anzeige der ZFS-Eigenschaften pro Dataset oder Verzeichnispfad liefert dann folgender Befehl:

zsf get all /

Die hier angezeigte, umfangreiche Liste der ZFS-Eigenschaften können Sie auch einzeln abfragen. So ist etwa eine Eigenschaft wie „compressratio“ mit

zfs get compressratio

global über den gesamten Pool zu ermitteln. Sicher gewöhnungsbedürftig sind dabei die ZFS-Pfadangaben wie „rpool/USERDATA/lw_0am7f7“ mit ID. Dass dies (in unserem Fall) mit /home/lw zu übersetzen ist, zeigt der bereits genannte Befehl „zfs list“.

Beispiel 1: ZFS-Snapshots

Wer Ubuntu mit ZFS installiert hat, sieht bei jeder Installation im Terminal Infos wie folgende (Beispiel):

Anforderung zur Speicherung des aktuellen Systemzustands

Erfolgreich als "autozsys okpszm" gespeichert

ZFS ist also unter Ubuntu soweit integriert, dass bei jeder Installation standardmäßig ein Snapshot entsteht. Dies gilt für Installationen aus den normalen Paketquellen im Terminal wie im grafischen Software-Center. zfs kann alle Snapshots auflisten:

zfs list -t snapshot [-o name,creation -s creation]

Was in eckiger Klammer steht, ist nicht zwingend, reduziert aber auf Snapshot-Namen und Erstelldatum und sortiert („-s“) nach dem Erstelldatum – neueste zuletzt. Snapshot-Namen bestehen aus dem ZFS-Pfad, gefolgt von einem „@“ und dem Namen des Snapshots. Eine Bezeichnung wie

rpool/USERDATA/lw_0am7f7@autozsys_w6sj7d

zeigt einen automatischen Snapshot („autozsys_…“) im Home-Verzeichnis /home/lw („rpool/USERDATA/lw_0am7f7“). Periodisch landen Snapshots auch im Grub-Menü. Damit kann der Systembenutzer über das Bootmenü zu einem früheren Systemzustand zurückkehren. Wird Systemstart mit Umschalt-Taste (Bios-Boot) oder Esc (Uefi-Boot) unterbrochen, dann zeigt Grub den zusätzlichen Eintrag „History for Ubuntu…“ und darunter dann die einzelnen Sicherungen (Beispiel):

Revert to 24.12.2020 @ 16:22

Mit dem Befehl

sudo zfs snapshot create […]

lassen sich Snapshots manuell erstellen – allerdings erwartet ZFS dabei die Pfadangabe gemäß seiner rpool-Verzeichnisstruktur:

sudo zfs snapshot rpool/USERDATA/lw_0am7f7@24.12.2020

Das ist eine Sicherung des Home-Verzeichnisses (von „/home/lw“), die später mit

sudo zfs rollback rpool/USERDATA/lw_0am7f7@24.12.2020

wiederhergestellt werden kann. Der Parameter „destroy“

sudo zfs destroy rpool/USERDATA/lw_0am7f7@24.12.2020

löscht nicht mehr benötigte Snapshots.

Beispiel 2: ZFS-Komprimierung

Mit seiner internen Komprimierung kann ZFS erheblich Platz sparen. Bei einer Ubuntu-Installation mit ZFS ist je nach Format der Benutzerdateien ein Platzgewinn von bis zu 50 Prozent zu erzielen. Die Komprimierung kann auch ad hoc für externe Datenträger genutzt werden. Im folgenden Beispiel bearbeiten wir einen USB-Stick (/dev/sde):

sudo zpool create -f stick32 /dev/sde

Dies bedeutet eine ZFS-Formatierung, die alle bisherigen Daten löscht. Danach liefert der Befehl

sudo zfs get all stick32

die Menge aller ZFS-Attribute und zeigt, dass die Eigenschaft „compression“ aktuell auf „off“ steht. Das ändert dieser Befehl:

sudo zfs set compression=lz4 stick32

Die erneute Abfrage der Eigenschaften zeigt nun bei „compression“ den Wert „lz4“. Das war’s schon. Der USB-Stick ist unter /stick32 im Dateisystem eingehängt und kann nun genutzt werden, nachdem der Benutzer mit

sudo chown -cR sepp:sepp /stick32

den Besitz übernommen hat.

Beispiel 3: ZFS-Verschlüsselung

Um einen verschlüsselten Bereich zu erstellen, beginnt man mit einem neuen Pool unter Angabe eines Namens und der Gerätekennung (hier: /dev/sde):

sudo zpool create mystick /dev/sde

Auf dem neuen Datenpool „mystick“ entsteht nun mit Namen „privat“ der verschlüsselte Bereich. Nach folgendem Befehl

sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase mystick/privat

wird zweimal das Passwort abgefragt.

Das Dateisystem BTRFS

BTRFS hat als der etwas kleinere ZFS-Konkurrent das Potential für den künftigen Linux-Standard am Desktop. Es bietet fundamentale Vereinfachungen für die Datenträger-Administration ohne die überdimensionierten Maße eines ZFS.

BTRFS (B-Tree-Filesystem, „Butter FS“, „Better FS“) gibt es seit 2007, ist seit 2009 im Linux-Kernel und gilt seit 2014 als stabil. BTRFS hat viele Gemeinsamkeiten mit ZFS und gilt als dessen kleineres Linux-Pendant, das besser auf die Leistung und die Anforderungen am Linux-Desktop- abgestimmt ist und keine zusätzlichen RAM-Ressourcen fordert. Dennoch bleiben die BTRFS-Spezialitäten vorerst „nur“ optional interessant und für ein typisches Desktop-System sicher nicht zwingend. Bemerkenswert ist die interne Datenkomprimierung, während Datenverschlüsselung (im Unterschied zu ZFS) weiterhin fehlt.

Als Formatierungsoption für interne wie externe Laufwerke hat BTRFS überall in den grafischen Werkzeugen wie Installer oder Laufwerksverwaltungen Einzug gefunden. Überwiegend findet der Umgang mit BTRFS aber im Terminal mit den Programmen statt, die das in der Regel vorinstallierte Paket „btrfs-progs“ (früher „btrfs-tools“) mitbringt. Das wichtigste dieser Tools nennt sich schlicht „btrfs“ und bringt eine Menge an Unterfunktionen mit. Dieser Beitrag hat nur Platz für die interessantesten Fähigkeiten von BTRFS.

BTRFS-Snapshots

BTRFS bietet Snapshots (Systemsicherungspunkte), um – mit einem einzigen Befehl – den aktuellen Partitionszustand zu sichern. Während grafische BTRFS-Tools, die über die grundlegende Formatierung (etwa mit Gnome-Disks) hinausgehen, den meisten Distributionen fehlen, hat Open Suse die Integration ein Stück verbessert. Das Konfigurationszentrum Yast2 bringt mit der Komponente Yast2-Snapper bringt die wichtige Snapshot-Verwaltung in grafischer Darstellung. Dort genügt ein Klick auf „Erzeugen“ für einen manuellen Schnappschuss und „Löschen“ für das Entfernen des markierten Eintrags. Der Punkt „Änderungen anzeigen“ führt zu einem Detailbericht für den markierten Schnappschuss, der gezieltes Zurückschreiben einzelner Dateien ermöglicht – eine kleinteilige Arbeit, die zumindest für Systemdateien gute Kenntnisse voraussetzt. Bedauerlich ist, dass der Yast2-Snapper kein komplettes Rollback zu einem früheren Zustand auslösen kann. Hierfür bietet Opensuse sein Bootmenü mit Auswahl der Snapshots, im laufenden Betrieb außerdem das Terminaltool Snapper:

sudo snapper list 

Dies zeigt zunächst sämtliche Snapshots mit Kennzahl. Dort suchen Sie den geeigneten Snapshot anhand des Datums und geben dann diesen Befehl

sudo snapper rollback [x] 

mit der zugehörigen Kennziffer ein. Danach starten Sie das System neu. Beim Rollback geschieht grundlegend anderes als beim Wiederherstellen einzelner Dateien im Yast-Modul: Hier hängt Snapper den kompletten Snapshot an die ursprüngliche Stelle ins Dateisystem ein und ersetzt dabei die bisherigen Daten.

Insgesamt erscheint die Snapshot-Integration in Open Suse prinzipiell verdienstvoll, aber für Desktop-Nutzer unzureichend. Wer sich mit BTRFS-Snapshots genauer befassen will, kommt trotz Yast2-Snapper und Konsolen-Snapper am zugrundeliegenden Basisprogrammen btrfs nicht vorbei (Beispiel):

sudo btrfs subvolume snapshot /home /home/snapshot.2021.01.01

Die Quelle – hier „/home“ – ist kein beliebig wählbarer Pfad, sondern muss ein existierendes BTRFS-Subvolume sein, welche wiederum der Befehl

sudo btrfs subvolume list /

liefern kann.

Snapshots sind auch bei größeren Laufwerken blitzschnell erledigt, da es sich vorläufig nur um einen Zeiger auf identische Dateiobjekte handelt. Erst bei Änderungen muss BTRFS die Originalversion für den Snapshot gesondert speichern. Der Snapshot wird dauerhaft den Originalzustand anzeigen und diesen erhalten, egal was im Originalordner geschieht. Ein „Rollback“, wie es Snapper nennt, gibt es eigentlich nicht: Vielmehr wird das bisherige Original ausgehängt und der Snapshot eingehängt.

BTRFS-Komprimierung auf SSD

BTRFS bietet für komplette Datenträger transparente (Hintergrund-) Komprimierung aller gespeicherten Dateien. Auf SSDs mit wenig Kapazität kann eine Linux-Installation mit BTRFS Platz sparen und obendrein den Datendurchsdatz erhöhen. Preis ist eine höhere Prozessorlast, was aber bei aktuellen CPUs kaum auffallen sollte. Wenn Linux mit BTRFS installiert wurde (was inzwischen auch Ubuntu & Co anbieten), lässt sich die optionale Komprimierung für das root-Dateisystem in der Datei /etc/fstab einrichten. Nach

sudo nano /etc/fstab

werden Sie eine gut gefüllte Datei mit diversen Subvolumes vorfinden. Für das root-Verzeichnis „/“ wird als Dateisystem „btrfs“ und in der Optionenspalte lediglich „defaults“ anzutreffen sein. Für zusätzliche Komprimierung ergänzen Sie die Option „compress“:

UUID=[Partitions-ID]  /  btrfs  defaults,compress 0  0

Theoretisch kann Analoges auch für „subvol=/@/home“ und weitere Subvolumes erfolgen.

BTRFS-Komprimierung auf USB

Wer Bedenken vor der Formatierung und Komprimierung eines Systemdatenträgers hat, sollte BTRFS immerhin für externe Laufwerke in Erwägung ziehen. Neben dem standardmäßig vorgesehenen

sudo mkfs.btrfs /dev/sd[x]

bieten auch die Gnome- und KDE-Laufwerkstools BTRFS-Formatierung. Falls die optionale Kompression gewünscht ist, sollte sie baldmöglichst nach der Formatierung aktiviert werden, da sie erst ab diesemZeitpunkt wirkt (vorher vorhandene Daten bleiben unberücksichtigt). Dies geschieht am Mountpunkt des eingehängten Laufwerks (hier „/media/sepp/btrfs-stick“):

sudo btrfs property set /media/sepp/btrfs-stick compression zstd

Das Attribut bleibt dann permanent gesetzt, auch nach Aushängen und erneutem Einhängen. Davon und von den aktuellen Eigenschaften eines BTRFS-Dateisystems können Sie sich mit

btrfs property get /media/sepp/btrfs-stick

jederzeit überzeugen. BTRFS-Kompression kann gerade bei langsamen USB-Laufwerken und Speicherkarten den Datendurchsatz deutlich verbessern.

BTRFS: Weitere Praxis-Beispiele

Konvertierung: Das Tool btrfs-convert (im Paket btrfs-progs enthalten) kann von einem Livesystem aus das Ext4-Dateisystem eines bereits installierten Linux zu BTRFS zu konvertieren. Wir raten ab – nicht aus empirischer Erfahrung, sondern aufgrund prinzipieller Vorsicht vor Eingriffen dieser Dimension.

Datenträger zusammenlegen: Folgender Befehl

sudo mkfs.btrfs /dev/sdc /dev/sdd

legt zwei (ausgehängte) Datenträger zu einem logischen Volume zusammen. Achtung – das ist eine Formatierung und eventuelle Daten auf den Laufwerken gehen verloren. Um diesen neuen Speicherplatz einzuhängen, benötigen Sie ein leeres Verzeichnis und einen Mount-Befehl:

sudo mount /dev/sdc ~/Sticks

Es spielt keine Rolle, welche der beiden Geräte-Kennungen Sie verwenden. Sie können später noch weitere Datenträger hinzufügen:

sudo btrfs device add /dev/sdf ~/Sticks/

Das gilt analog auch für root-Dateisystem („/“), falls dort der Speicherplatz knapp wird:

sudo btrfs device add /dev/sdf /

Größenänderungen: Wie schnell BTRFS Größenänderungen auf einem Volume oder einem Verbund erledigt, zeigt dieser Befehl:

sudo btrfs filesystem resize -10g /

Das verkleinert das root-Dateisystem um 10 GB.

Windows-Dateisysteme unter Linux

Für eine Linux-Installation stehen die Windows-Dateisysteme NTFS, FAT32 und exFAT nicht zur Diskussion. Ganz anders sieht es bei externen Datenträgern aus, die unter verschiedenen Betriebssystemen und Geräten genutzt werden sollen.

Selbst kompromisslose Linux-Anwender sind gut beraten, auf das verbreitete Windows Rücksicht zu nehmen. USB-Sticks oder USB-Festplatten sind unter Windows schlicht nicht verwendbar, wenn die Datenträger mit einem Linux-Dateisystem formatiert sind (Ext, XFS, BTRFS, ZFS…). Die Windows-Reaktion „Sie müssen den Datenträger formatieren…“ ist borniert bis arrogant, weil Microsoft zweifellos in der Lage wäre, zumindest ein Ext4 einzubinden. Aber diese Weigerung ist seit Jahren Status Quo und wird sich auch nicht zeitnah ändern. Daher ist es fast unausweichlich, für mobile Laufwerke (eventuell auch in weiteren Situationen) auf ein Microsoft-Dateisystem auszuweichen.

FAT32: Limitiert, aber unkompliziert

Das alte FAT32 (seit 1996) hat gegenüber moderneren Nachfolgern nur einen großen Pluspunkt – es ist wirklich unter jedem PC-System (alte und neue Linux-, Windows-, Mac-OS-Versionen) lesbar und beschreibbar. Unterhaltungselektronik wie Smart-TVs, Hifi-Receiver oder Auto-Soundsysteme werden am USB-Port in jedem Fall einen FAT32-Datenträger einlesen. Sämtliche PC-Betriebssysteme können Datenträger auch selbst mit FAT32 formatieren. Da FAT32 außer zwei Zeitstempel keine Metadaten und keine Dateirechte anbietet, eignet es sich ausschließlich als Datencontainer insbesondere für USB-Sticks. Das Größenlimit für den Datenträger von 32 GB unter Windows ist künstlich (siehe unten).

4-GB-Datei-Limit: Entscheidender ist das FAT32-Limit für eine einzelne Datei von 4 GB. IMG- und ISO-Dateien überschreiten diese Größe häufig ebenso wie hochauflösende Filmdateien. Während Windows das Größenproblem im Falle des Falles sofort meldet, kopiert Linux bis zum Erreichen der Grenze und bricht erst dann mit einer Fehlermeldung ab. Für USB-Medien, die keine riesigen Imagedateien oder Filmdateien aufnehmen müssen, reicht FAT32 aber völlig aus.

32-GB-Datenträger-Limit: Bei USB-Sticks, -Festplatten, SD-Karten größer als 32 GB unterschlägt Windows beim Formatieren die Option „FAT32“ und schlägt nur „NTFS“ und „exFAT“ vor, als wäre dies bei Datenträgern dieser Größe technisch nicht anders möglich. Das müssen Sie nicht akzeptieren, wenn ein Linux im Haus ist. FAT32 kann problemlos auch große Datenträger verwalten, indem es einfach die Blockgröße entsprechend hochskaliert. Verwenden Sie etwa Gnome-Disks oder den KDE-Partitionmanager zum Formatieren. FAT32 erscheint dort in der Regel einfach als „FAT“, zum Teil auch erläutert als „Kompatibel mit allen Systemen…“.

USB-Medien mit Livesystemen / Multiboot-Livesystemen: Im Unterschied zu installiertem Linux laufen Linux-Livesysteme sehr wohl auf auch auf FAT32. In den meisten Fällen ist hier FAT32 sogar notwendig oder empfohlen. Tools wie Unetbootin (http://unetbootin.github.io/) zum Erstellen von Livesystemen oder Tools wie Yumi(www.pendrivelinux.com/yumi-multiboot-usb-creator) zum Einrichten von Multiboot-Livesystemen setzen eine FAT32-Formatierung schlicht voraus.

exFAT: „Großer“ Datenaustausch

exFAT ist ähnlich simpel wie FAT32 und besitzt keine Metadaten für Rechte. Entscheidender Unterschied zu FAT32 ist die unlimitierte Größe für Einzeldateien. Wer ISO/IMG-Images und Filme zwischen Linux und Windows austauschen will, kann mit exFAT auf USB- und SD-Datenträger wenig falsch machen. Nachdem der Dateisystemtreiber Einzug in den Linux-Kernel gefunden hat, ist exFAT unter Linux größtenteils ohne Nachhilfe nutzbar. Auch grafische Werkzeuge wie Gnome-Disks („Partition formatieren -> Andere -> exFAT“) bieten inzwischen direkte exFAT-Unterstützung, und Dateimanager laden entsprechende Datenträger automatisch. Ausnahme: Der Partitionierer Gparted hat exFAT zwar in seiner Dateisystemliste, will aber bislang nicht mit exFAT formatieren (inaktiv).

SDHX-Karten: Der jüngere SDHX-Standard bei SD-Karten, der sehr große Kapazitäten erlaubt, empfiehlt grundsätzlich eine Formatierung mit exFAT.

Exorbitante Blockgröße: Während sich normale Blockgrößen (Cluster) bei Dateisystemen im KB-Bereich bewegen, kann die maximale Blockgröße bei exFAT theoretisch bis zu 32 MB betragen! Aus diesem Grund kann das relativ einfache Dateisystem praktisch beliebig große Datenträger adressieren. Empirisch lassen sich unter Linux aber offenbar „nur“ maximal 4-MB-Blöcke einrichten, und dies auch nur im Terminal:

sudo mkfs.exfat -s 8192 /dev/sd[x][n]

Die von vier MB völlig abweichende Zahl „8192“ ergibt sich aus der Vervielfachung der kleinsten Einheit „1“, die 512-Byte-Cluster erstellt. Wenn von vornherein klar ist, dass ein Laufwerk ausschließlich sehr große Dateien aufnehmen wird, dann ist eine derart extreme Formatierung durchaus sinnvoll und beschleunigt alle Dateivorgänge. Für kleine Dateien bedeutet das hingegen pure Platzverschwendung. Dies gilt im Prinzip für alle Dateisysteme, ist aber bei dem ungewöhnlichen exFAT eine besondere Erwähnung wert.

Nachinstallation: Wo exFAT unter Linux tatsächlich noch fehlen sollte, ist es mit

sudo apt install exfat-fuse exfat-utils

schnell nachgerüstet (im Beispiel für Debian/Ubuntu & Co).

NTFS: Auf USB kontraproduktiv

Sofern nicht dumme Geräte der Unterhaltungselektronik berücksichtigt werden müssen, scheint NTFS auf den ersten Blick die beste Wahl für Austauschdatenträger. Das trifft aber nur bedingt zu. Externe USB-Datenträger mit NTFS-Formatierung rangieren unter Linux im Prinzip als rechteloses FAT-Dateisystem: Wenn Linux-Standardbenutzer – Systemverwalter sowieso – externe Geräte ein- und aushängen, erhalten sie auf NTFS-Partitionen (wie auf FAT32 oder exFAT) vollen Lese- und Schreibzugriff. Das sollte zunächst auf einem Austauschdatenträger nicht stören, kann aber erheblich stören, wenn von Windows-Seite spezielle NTFS-Eigenschaften aktiviert wurden. Dateien, für die etwa unter Windows Komprimierung oder Verschlüsselung angefordert wurde, werden unter Linux nicht ankommen. Andererseits wird Linux eingestellte NTFS-Benutzerrechte ignorieren.

Mit anderen Worten: NTFS ist als Austauschformat solange in Ordnung, als seine eigentlichen Fähigkeiten nicht genutzt werden und es nur als unkompliziertes Containerformat dient. Dann kann man aber gleich zum simplen FAT32 oder exFAT greifen.

FAT32 / exFAT und Samba-Freigaben

Datenträger mit rechtelosen Dateisystemen per Samba freizugeben, ist ein absoluter Komfort-Tipp für faule Heim-Administratoren. Dateirechte fallen komplett weg und es zählen nur noch die Netzwerkrechte, die in der Samba-Konfigurationsdatei (/etc/samba/smb.conf) mit wenigen Zeilen definiert sind:

[exfat]
path = /media/sepp/toshiba 
write list = sepp 
browseable = yes 

Wer sich als „sepp“ ausweisen kann (Benutzer- und Samba-Konto sind natürlich Voraussetzung), kann auf dieser (exFAT-) Freigabe mit vorhandenen und neu erstellten Dateien machen, was er will.