Infos zu Linuxguides: Dateisysteme

[XXXBold]

Inhaltsverzeichnis
Übersicht
Erforderliche Vorkenntnisse
Verzeichnisstruktur

Einige Befehle​

Formate
Hilfe und Support
Empfehlungen/Erfahrungen des Autors
Feedback, Kritik, Wünsche
Änderungen
TODO-Liste

Übersicht

Dieser Thread enthält tiefergehende Informationen zum Thema Dateisystem und stellt eine Erweiterung des Inhalts aus dem Meta-Guide dar. Für eine kurze Übersicht zum Thema siehe die entsprechenden Abschnitte im Meta-Guide.

Erforderliche Vorkenntnisse

Für Einsteiger ist das Lesen des kompletten Meta-Guides vor diesem Thread empfehlenswert. Hierfür gelten dieselben Vorkenntnisse wie im Meta-Guide, zusätzlich ist die Bereitschaft nötig, sich mit dem Terminal und einigen Befehlen dazu auseinanderzusetzen.

Verzeichnisstruktur

Unter dem Rootverzeichnis befinden sich diverse Unterverzeichnisse, welche im Grossen und Ganzen ähnlich sind, jedoch gibt es Unterschiede zwischen den Distributionen. Hier werden einige der Verzeichnisse und deren Bedeutung genauer erläutert.

'/home/' - Enthält die Konfigurationen und persönlichen Daten der vorhandenen Benutzer auf dem System. Jeder Benutzer hat ein eigenes Unterverzeichnis, welches gleich wie der Benutzername heisst. In diesen Verzeichnissen befinden sich sowohl Konfigurationen als auch Dokumente, Bilder und weitere Daten eines Benutzers. Für ein Backup ist dieses Verzeichnis also besonders interessant.
'/etc/' - Hier befinden sich globale, systemweite Konfigurationen, welche für alle Benutzer gültig sind. Je nach Applikation speichern diese im jeweiligen HOME-Verzeichnis nutzerspezifische Einstellungen, welche denen von '/etc/' vorgezogen werden.
'/root/' - Das HOME-Verzeichnis des Benutzers root.
'/usr' - Enthält die meisten Systemressourcen, darunter ausführbare Dateien und dazu nötige Bibliotheken.
'/bin/' + '/usr/bin/' - In diesen Verzeichnissen sind ausführbare Dateien (analog der .exe-Dateien unter Windows) vorhanden.
'/tmp/' - Enthält temporäre Dateien, sollte nach jedem Systemneustart automatisch gelöscht werden.
'/dev/' - Enthält Daten zu Hardware und Peripherie. Unter Linux ist generell alles eine Datei, also auch die Geräte im System. Dieses Paradigma stammt von UNIX und lebt auch in Linux weiter: https://en.wikipedia.org/wiki/Everything_is_a_file

Mehr Infos dazu: https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Jedes Verzeichnis enthält ausserdem die speziellen Verzeichnisse '.' und '..'.
'.' - Link zum aktuellen Verzeichnis
'..' - Link zum übergeordneten Verzeichnis

Einige Befehle

Zum arbeiten in den Verzeichnissen existieren diverse Befehle. Einige wichtige sind:

• ls - Listet Dateien und Unterverzeichnisse des aktuellen Verzeichnisses auf
• pwd - Aktuelles Arbeitsverzeichnis ausgeben
• cd - Zu neuem Verzeichnis navigieren
• mkdir - Neues Verzeichnis anlegen
• rm - Datei(en) löschen
• rmdir - Verzeichnis löschen

Formate

Unter Linux sind unterschiedliche Dateisystemformate im Einsatz. Hier werden die am häufigsten genutzten aufgelistet.

Format	Beschreibung	Vorteile	Nachteile
ext4 https://de.wikipedia.org/wiki/Ext4	Standard bei vielen Systemen, von allen Distributionen unterstützt und am weitesten verbreitet	+ Sehr etabliert Stabil Guter Datendurchsatz Unterstützt Verschlüsselung	- Schützt nicht vor Bit rot
btrfs https://de.wikipedia.org/wiki/Btrfs	Möglicher Nachfolger von ext4, im allgemeinen mehr auf Datensicherheit fokussiert als dieses.	+ Integriertes Volumen- und RAID Management + Mechanismen zum detetektieren von Bit rots	- Noch bestehende Probleme mit Datenverlust bei RAID 5/6
ZFS https://en.wikipedia.org/wiki/OpenZFS	Ähnliche Feature wie btrfs, bereits etwas ausgereifter, allerdings nicht im Kernel enthalten.	+ Integriertes Volumen- und RAID Management Mechanismen zum detetektieren von Bit rots Ausgereifter als btrfs	- Aufgrund von Lizenrechtlicher Inkompatibilität nicht im Linuxkernel
XFS https://de.wikipedia.org/wiki/XFS_(Dateisystem)	XFS ist ein älteres Dateisystem, das sich durch seinen hohen Datendurchsatz auszeichnet	+ Bereits ausgereift und stabil + Von den meisten Distributionen unterstützt	- Einige Funktionen nicht mehr zeitgemäss oder aufwändig - Datensicherheit nicht immer gewährleistet (z.B. Stromausfall)
bcachefs https://en.wikipedia.org/wiki/Bcachefs	bcachefs ist ein noch junges Dateisystem, seit 6.7 im Kernel, welches aktuell noch als experimentell gilt. Das Ziel ist es, Features von btrfs/ZFS mit besserer Geschwindigkeit zu bieten.	+ Interessantes Featureset	- Noch experimentell
F2FS https://en.wikipedia.org/wiki/F2FS	F2FS ist eine alternative zum bestehenden exFAT, vorallem interessant für "einfachere" Systeme mit NAND-Speicher, wie Mobilgeräte und ähnliches.	+ Besseres Featureset als (ex)FAT	- Kein journal

Bei den meisten Desktopdistributionen wird standardmässig ein ext4-Dateisystem erstellt, weshalb dieses Format im Desktop auch am häufigsten vorkommt. Neueinsteigern sei, sofern sie zur Wahl gestellt werden, dieses Format nahegelegt.

Hilfe und Support

• man-Pages online: https://linux.die.net/man/
• Übersicht Dateisysteme: https://de.wikipedia.org/wiki/Liste_von_Dateisystemen#Linux

Empfehlungen/Erfahrungen des Autors

Für den Einstieg mögen einige Informationen nicht nötig sein, allerdings ist ein Verständnis des Dateisystems unentbehrlich, wenn sich jemand mit Linux tiefer beschäftigen will. Ich empfehle daher, sich mit den Themen dazu gut vertraut zu machen.

Feedback, Kritik, Wünsche

Für Feedback/Wünsche zu diesem Beitrag: Hier rein. Für Verbesserungsvorschläge: Bitte zuerst die TODO-Liste prüfen, ob das Thema bereits vorhanden ist. Wollt ihr selber ein Kapitel für das Thema schreiben oder überarbeiten, bitte ich um Kontaktaufnahme per PN.
Der Thread wird von mir nach bestem Wissen und Gewissen erstellt. Es ist möglich, dass einige Information nicht 100% korrekt oder unvollständig sind, für Hinweise bin ich dankbar, auch gerne per PN wenn ihr nicht direkt hier posten wollt.

Änderungen

• 23.05.2020 - Thema erstellt
• 28.05.2020 - Tabellenform für Formate, mit Vor- und Nachteilen
• 21.08.2024 - Neue FS der Tabelle hinzugefügt, danke für die Hinweise!

TODO-Liste

• Kapitel über Partitionen (ggf. eigenes Thema?)

 

[madmax2010]

Zu ZFS kann ich gern helfen wenn du magst.
Zu BTRFS Ist der talk super und kann sicher gut zu weiteren Inhalten anregen: https://media.ccc.de/v/froscon2015-1549-btrfs_das_dateisystem_der_zukunft
Allgemein macht sicher auch Sinn inodes zu erklären - die sind bei klassischen Unix*oiden Dateisystemen ja schon irgendwie echt relevant

 

[HisN]

Und nicht DAS geniale Fuse vergessen :-)

 

[Thermi]

XFS nicht vergessen. Ist bei jeder CentOS-7-Installation das Standard-FS. Btw, man hier zeigt dir die Man-Page für die Dateisystemhierarchie an.

 

[madmax2010]

Und nicht DAS geniale Fuse vergessen :-)

Uff. DAS fuse. Guter

 

[XXXBold]

Danke für die Vorschläge. Für die neuen, vorgeschlagenen Dateisysteme wäre ich froh, wenn ihr selbst einige Eigenschaften und ein paar Vor-und Nachteile dazu nennen könntet. Muss nicht viel sein, 2-3 Sätze als Beschreibung dazu reichen aus.

 

[Iapetos]

Zu ZFS kann ich gern helfen wenn du magst.
Zu BTRFS Ist der talk super und kann sicher gut zu weiteren Inhalten anregen: https://media.ccc.de/v/froscon2015-1549-btrfs_das_dateisystem_der_zukunft
Allgemein macht sicher auch Sinn inodes zu erklären - die sind bei klassischen Unix*oiden Dateisystemen ja schon irgendwie echt relevant

Danke für den Link! Ich spiele seit einiger Zeit mit dem Gedanken, wegen der Datenprüfsummen auf btrfs-raid1 zu wechseln. Metadatenprüfsummen funktionieren ja nun schon auch auf xfs und ext4, die genügen aber nicht gegen Bitrot...

Habe es bisher in einer VM getestet, bisher scheint Fedora damit recht gut zurecht zu kommen. Leider liest man immer dann Schlechtes (Datenverlust bzw. Dateisystemkorruption) über btrfs, wenn man explizit nach Erfahrungsberichten sucht.

 

[madmax2010]

Jo, ist bei dateisystemen in ihren ersten jahren immer so.. Wenn man man an die alten ext / die frühen tage von zfs@solaris denkt..

 

[Piktogramm]

@Iapetos
BTRFS ist stable, da halten sich leider viele Erzählungen aus alter Zeit. Das Einzige Problem ist das Writehole in der Raid 5/6 Konfiguration. Ein Problem welches jedoch ebenso mit Raid 5/6 über mdadm auftreten kann und besondere Voraussetzungen benötigt (https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg79535.html).
ZFS kann diesen Sonderfall abfangen.

 

[Iapetos]

Danke für die Info.

Raid5 und 6 sind für mich sowieso uninteressant, da ich keinen Storage-Server betreibe. Mir geht es in erster Linie darum, meine gesammelten Daten konsistent zu halten und vor gekippten Bits zu bewahren. OpenZFS kommt für mich leider nicht infrage, weil ich keine Lust habe, nach jedem Kernel-Upgrade das DKMS-Modul neu zu signieren; das selbe gilt für Reiser4. Die Flexibiltät von btrfs, gerade bzgl. Snapshots und (inkrementelle) Backups (btrfs-send) ist außerdem verlockend, dazu kommt, dass es sowieso dem Kernel beiliegt.

Zudem beobachte ich noch bcachefs als kleine, ressourcenschonende Alternative mit stabilem Kern.

 

[Caramon2]

Hier ein aktueller Vergleich der geläufigsten Dateisysteme:

An Initial Benchmark Of Bcachefs vs. Btrfs vs. EXT4 vs. F2FS vs. XFS On Linux 6.11

F2FS passt nicht ganz dazu, da kein Journaling. Das ist eher das Gegenstück zu exFAT, nur bei weitem nicht so primitiv.

OpenZFS wasn't used for this round of testing since it doesn't yet support the Linux 6.11 (or 6.10) kernels in released form.

Der 6.9 hat schon vor einer Woche sein EOL erreicht.

 

[jenzen]

Ich hatte in dem Post hier: https://www.computerbase.de/forum/t...tion-unter-linux.2205498/page-4#post-29666561
ein paar Vorteile und auch Nachteile von modernen FS wie btrfs und bcachefs genannt. bcachefs fehlt in deiner Auflistung, solltest du mit aufnehmen, da es sehr spannend ist, aktuell aber noch ziemlich neu und damit noch nicht wirklich ausgereift. F2FS fehlt in deiner Auflistung auch noch.

 

[XXXBold]

Danke euch beiden, habe die Tabelle ergänzt.

 

[Caramon2]

@XXXBold: Vielleicht kannst du das noch brauchen:

1. Wenn man ext4 standardmäßig formatiert, ist das unvollständig. Erst wenn man die Partition einhängt, wird die Formatierung vervollständigt, wodurch es je nach Größe der Partition minutenlang Zugriffe, bis die Formatierung endlich abgeschlossen ist.

Mit der mkfs.ext4 Option "-E lazy_itable_init=0,lazy_journal_init=0" kann man die vollständige Formatierung erzwingen:

lazy_itable_init[= <0 to disable, 1 to enable>]
       If enabled and the uninit_bg feature is enabled, the inode table will not
       be  fully  initialized by mke2fs.  This speeds up file system initializa‐
       tion noticeably, but it requires the kernel to  finish  initializing  the
       file  system in the background when the file system is first mounted.  If
       the option value is omitted, it defaults to 1 to enable lazy inode  table
       zeroing.

lazy_journal_init[= <0 to disable, 1 to enable>]
       If  enabled,  the  journal  inode will not be fully zeroed out by mke2fs.
       This speeds up file system initialization noticeably,  but  carries  some
       small  risk if the system crashes before the journal has been overwritten
       entirely one time.  If the option value is omitted, it defaults to  1  to
       enable lazy journal inode zeroing.

2. btrfs ist standardmäßig ziemlich langsam (s. u. - aber auch im Betrieb auf der Home-Partition fühlt es sich sehr zäh an, wenn man dort jahrelang xfs gewohnt ist - auf einer MX500 v1), was man mit der mkfs.btrfs Option "-O block-group-tree" fast ganz weg bekommt:

block-group-tree
       (kernel support since 6.1)

       Enable a dedicated b-tree for block group items, this greatly reduces mount time  for
       large  filesystems due to better data locality that avoids seeking. On rotational de‐
       vices the large size is considered starting from the 2-4TiB. Can  be  used  on  other
       types of devices (SSD, NVMe, ...) as well.

       Offline conversion from filesystems that don't have this feature enabled at mkfs time
       is possible, see btrfstune(8). Online conversion is not possible.

Das kann man mit "btrfstune" auch nachträglich aktivieren, was sofort einen Effekt hat. Also es ist sofort "schnell", als wäre es gleich mit der Option formatiert worden.

Anbei ein Vergleichsvideo ohne die Option, das ich mal gemacht habe:

Beide 3,5" Sicherungsplatten sind quasi identisch (s. Seriennummer), da gemeinsam zusammen mit den USB3-Gehäusen bestellt.

Um Unterschiede möglichst auszuschließen, hatte ich beide Platten zuerst vollständig mit Nullen überschrieben, dann neu aufgesetzt und ca. 1. Monat lang immer direkt nacheinander aufgeführt (per rsync + Hardlinks mehrstufig - s. u.), damit beide Platten möglichst die selben Daten und Änderungen in der selben Reihenfolge bekommen.

Das Video zeigt, dass das entsperren beider Platten gleich schnell ist, aber das Einhängen der Dateisysteme bei btrfs sehr viel länger dauert (ca. 5x), wie auch das einlesen der Dateieigenschaften meines Videoarchivs (fast 10x !).

Wie gesagt: Auch im normalen Betrieb auf der Homepartition hat das immer wieder genervt.

Nachdem ich die Option per "btrfstune" auch nachträglich aktiviert hatte, war btrfs schlagartig fast genauso schnell wie xfs: Einen Unterschied konnte ich nicht erkennen, nur anhand einer Videoaufzeichnung feststellen: Bei btrfs dauerten einhängen und Dateieigenschaften jeweils ein paar Frames länger.

Und auch die Home-Partition fühlte sich anschließend nicht mehr wie mit angezogener Handbremse an.

---

Mein Sicherungsskript:

#!/bin/bash
zs=9  # höchste Sicherungsstufe
if [ ! -d Sicherungen ];then mkdir Sicherungen || exit;fi
cd Sicherungen/
mv Artix_$zs Artix_bak 2>/dev/null
for ((z=$zs;z>=0;z--));do mv Artix_$z Artix_$((z+1)) 2>/dev/null;done
if [ ! -d Artix_bak ];then mkdir Artix_0;else mv Artix_bak Artix_0;fi
espeak-ng -vde "Bitte Passwort." & sudo sync -f .
echo
time sudo rsync -vaxH --link-dest=../../Artix_1/linux/ --exclude '.cache/*' --exclude '/home/*' --exclude '/tmp/*' --exclude '/var/tmp/*' --exclude '/var/log/*' --exclude '*.log' --exclude '*.old' --exclude '*_old' / Artix_0/linux/
echo
time sudo rsync -vaxH --link-dest=../Artix_1/ --exclude '.cache/*' --exclude '*.log' --exclude '*.old' --exclude '*_old' /home Artix_0/
echo;touch Artix_0
time sync -f .;echo
espeak-ng -vde "Datensicherung abgeschlossen." & read -p [Enter]

Nutzung auf eigene Gefahr: Ich habe eine Linux- und eine Home-Partition und nutze keine Snapshots (also auch nicht diesen @-Kram von btrfs), so dass die Sicherung mit und auf jedem Dateisystem funktioniert, solange manauch nur diese beiden Partitonen für sein System nutzt.

Hat man z. B. auch /boot eine eigene Partition gegeben und/oder nutzt eine andere Verschlüsselung, als die komplette Home-Partition (nicht aber das System) per LUKS zu verschlüsseln, oder nutzt diesen Snapshot-@-Kram, wird die Sicherung zwar auch funktionieren, aber mit der Wiederherstellung (z. B. von einem Livesystem aus mit "rsync -vaxH --del [Quelle] [Ziel]") wird man sich wahrscheinlich das System zerschießen.

 

[ropf]

Erwähnenswert wären für noch die Mount-Optionen noatime bzw. relatime, besonders auf SSDs.

Hintergrund: Linux speichert per default die Zeit des letzten Zugriffs (atime) in jeden einzelnen Datenblock des Dateisystems. Das bedeutet permanente Schreibzugriffe, auch wenn eigentlich nur gelesen werden soll, was auf Performance und Lebensdauer drückt.

Nur wenige Anwendungen (Datenbanken?) sind jedoch tatsächlich auf diese Zeitstempel angewiesen - weshalb sich dieses Verhalten komplett unterdrücken lässt (noatime) - oder so modifizieren, dass die Zeitstempel nur bei tatsächlich geänderten Daten neu gesetzt werden (relatime).

Moderne Distros setzen standardmässig relatime - aber wenn man ihnen bei der Partitionierung manuell dazwischenfunkt, ist das nicht mehr automatisch gegeben.

Ein nachträglicher Blick lohnt also - meine SSD im Laptop bleibt seitdem jedenfalls deutlich kühler.

 

[Caramon2]

Ob das mit bcachfs jemals was wird: Linus Torvalds Begins Expressing Regrets Merging Bcachefs

Dieser Kent Soundso scheint ziemlich unverbesserlich zu sein. Immer wieder der gleiche Ärger mit dem.

 

[schrht]

Klassischer Fall von "Ich bin der Hauptcharakter". Alle anderen Maintainer:innen müssen sich an die üblichen Prozesse halten, aber für ihn gilt das nicht weil sein Code ja offensichtlich besser ist. Das Drama gab's letztes Jahr schon, das selbe Kindergartenspiel spielen wir jetzt anscheinend noch einmal.

 

[jenzen]

bcachefs ist noch jung und daher passiert noch viel in der Entwicklung. Scheinbar zu viel für die jeweiligen Kernel Merge-Fenster, laut Torvalds. Das könnte sich auch noch legen. Der Entwickler könnte auch einfach einen Gang runterschalten und sich an die Vorgaben halten und nicht versuchen, noch weitere Features mit reinzuquetschen nur in der Hoffnung dass er es damit ins nächste Kernel-Release schafft. Bei einem FS ist aus meiner Sicht Zuverlässigkeit wichtiger als Entwicklungsgeschwindigkeit. Verstehe deshalb die Eile des Entwicklers nicht so. Setzt durch sowas auch seine Reputation etwas aufs Spiel.

 

[Piktogramm]

@jenzen
Es regt sich Keiner auf, dass da große Brocken im Mergefenster kommen. Es wird sich aufgeregt, dass während des Fensters für Bugfixes fette Commits kommen und das auch für Teile außerhalb des bcachefs Zweigs.

Und mit Eile ist es nicht begründbar, so oder so ist bcachefs ein gutes Stück davon entfernt alle Features stabil zu haben.