In Fedora 33 gibt es abseits der üblichen Versions-Updates drei vier grundlegende Neuerungen:
- Als minimaler Texteditor ist
nano
vorinstalliert, nichtvim
. Persönlich empfinde ich das als großen Fortschritt. Allevi
-Freunde müssen ebendnf install vim
ausführen (so wie ich nach jeder Linux-Installationdnf/apt install joe
ausführe, damit mir der Mini-Emacsjmacs
zur Verfügung steht). -
Das Defaultdateisystem für die Desktop-Version von Fedora lautet nun
btrfs
und nicht mehrext4
. (Details dazu folgen gleich.) -
Als lokaler DNS-Client kommt
systemd-resolved
zum Einsatz. -
Update 29.10.2020: Standardmäßig wird weder eine Swap-Datei noch eine Swap-Partition eingerichtet. Stattdessen werden bei Bedarf Datenblöcke komprimiert in ein ZRAM-Device ausgelagert.
Überraschenderweise wird Fedora in diesem Fall seiner Vorreiterrolle nur teilweise gerecht. (open)SUSE verwendet btrfs
schon seit Jahren standardmäßig. systemd-resolved
kommt wiederum in Ubuntu schon seit geraumer Zeit zum Einsatz (wenn ich mich recht erinnere, seit Version 18.04).
btrfs
Das Dateisystem btrfs
gilt mittlerweile als ausgereift. Nicht nur (open)SUSE setzt es standardmäßig ein, auch Facebook und Synology sind von den Vorzügen dieses Dateisystems überzeugt. Dessen ungeachtet war ich immer ein wenig skeptisch, ob btrfs
das ideale Dateisystem für Privatanwender ist (und bin dies nach wie vor): Die Administration ist deutlich komplexer als bei einem simplen ext4
-Dateisystem.
Im Gegensatz zu openSUSE verzichtet Fedora darauf, unzählige Subvolumes mit unterschiedlichen Eigenschaften zu definieren. Stattdessen ist das Default-Setup denkbar einfach: Es gibt (falls notwendig) ein VFAT-Dateisystem für EFI, ein ext4
-Dateisystem für /boot
und ein btrfs
-Dateisystem für die Subvolumes /
und /home
. Entsprechend übersichtlich sind die Datei /etc/fstab
und die Ergebnisse der Kommandos mount -t btrfs
oder df -t btrfs
.
Das einfache Setup hat allerdings den Nachteil, dass manche Features von btrfs
nicht optimal genutzt werden: Zum einen wäre es schön, wenn (zumindest für manche Verzeichnisse) die Komprimierfunktion von btrfs
aktiviert würde. Zum zweiten ist der Copy-on-Write-Ansatz von btrfs
für manche Anwendungen (Datenbanksysteme, Virtualisierung) langsam. Abhilfe schaffen eigene Subvolumes, in denen CoW deaktiviert ist. Zu guter Letzt könnten dnf-Operationen durch Snapshots abgesichert werden.
Die Fedora-Entwickler denken über diese in openSUSE bereits implementierten Features ebenfalls nach und wollen, wenn sich btrfs
in Fedora 33 bewährt, mehr btrfs
-Funktionen mit Fedora 34 liefern. (Dann werde ich an dieser Stelle kritisieren, dass btrfs
zu komplex ist …)
systemd-resolved
systemd-resolved
ist ein Network Name Resolution Manager, also ein Programm, das herausfindet, welche IP-Adresse einem Hostnamen wie kofler.info zugeordnet ist. systemd-resolved
merkt sich die IP-Adressen der zuletzt angefragten Hostname und agiert somit auch als DNS-Cache.
/etc/resolv.conf
verweist nicht, wie dies früher üblich war, auf die IP-Adressen der externen Nameserver, sondern vielmehr auf die lokale IP-Adresse 127.0.0.53 des Programms systemd-resolved
. Welche externe DNS-Server tatsächlich zum Einsatz kommen, verrät resolvectl status
.
Swap on ZRAM
Beim ersten Test glatt übersehen habe ich, dass der Fedora-Installer standardmäßig keine Swap-Partition mehr einrichtet. Ubuntu macht das auch nicht mehr, dort gibt es aber stattdessen eine Swap-Datei, die diese Rolle übernimmt. Was macht aber Fedora, wenn so viele speicherintensive Prozesse laufen, dass das RAM zur Neige geht?
Während des Systemstarts wird das Device /dev/zram0
wie eine Swap-Partition eingerichtet. Das Device beansprucht anfänglich keinen Speicherplatz. Die maximale Größe (unkomprimiert) wird je nach Größe des RAMs festgelegt, z.B. 4 GiB, wenn 16 GiB RAM zur Verfügung stehen.
Wenn der Arbeitsspeicher knapp wird, lagert der Swap-Mechanismus des Kernels Speicherblöcke in die Swap-Partition aus. Da sich diese ebenfalls im RAM befindet, sieht das nach einem Nullsummenspiel aus. Der Clou besteht darin, dass die Datenblöcke in /dev/zram0
automatisch komprimiert werden, wobei der sehr schnelle LZO-Algorithmus zum Einsatz kommt. Anders als bei einem echten Swap-System wird also nicht 1:1 so viel RAM frei, wie Speicherblöcke ausgelagert werden.
Der wesentliche Vorteil von Swap on ZRAM besteht darin, dass der Swap-Speicher trotz der Komprimierung deutlich schneller ist als bei einer herkömmlichen Konfiguration mit einer Swap-Partition oder -Datei auf einem physischen Datenträger. Informationen über die maximale Größe des Swap-Speichers (unkomprimiert) sowie über die aktuelle Nutzung gibt wie üblich swapon -s
. Wie gut die Komprimierung des Swap-Speichers gelingt, verrät das relativ neue Kommando zramctl
:
ls -l /dev/zram0
brw-rw----. 1 root disk 251, 0 Oct 29 08:21 /dev/zram0
cat /sys/block/zram0/disksize
2009071616 (max. Größe in Byte)
swapon -s
Filename Type Size Used Priority
/dev/zram0 partition 1961980 0 100
^
(max. Größe in 1k-Blöcken)
zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 1.9G 4K 74B 12K 2 [SWAP]
Mehr Details zur Motivation dieses Features sowie zur technischen Umsetzung sind hier protokolliert.
Installation
Beim Wettstreit, welche Distribution die einfachste Desktop-Installation anbietet, hat Fedora aktuell die Nase vorn — zumindest solange Sie nichts an der Default-Partitionierung verändern möchten. Nach der Einstellung der Sprache können Sie gleich weiter auf Installation starten drücken.
Unerfreulich wird die Angelegenheit aber, wenn Sie statt btrfs ein anderes Dateisystem wünschen oder sonst eine Änderung an der Partitionierung vornehmen möchten. Dann müssen Sie eine manuelle Partitionierung vornehmen, die unübersichtlich wie eh und je ist. Das können beinahe alle anderen Distributionen besser.
Versionsnummern
Basis Desktop Programmierung Server
--------------- ------------------ -------------- --------------
Kernel 5.8 Gnome 3.38 bash 5.0 Apache 2.4
glibc 2.32 Firefox 81 gcc 10.2 CUPS 2.3
X-Server 1.20 Gimp 2.10 Java 8/11/15 MariaDB 10.4
Wayland 1.18 LibreOffice 7.0 PHP 7.4 OpenSSH 8.4
Mesa 20.2 Thunderbird 78 Python 3.9 qemu/KVM 5.1
Systemd 246 Postfix 3.5
NetworkMan 1.26 Samba 4.13
GRUB 2.04
Quellen und Links
- Download
- Release Notes
- Change Set
- Common Bugs
- What’s new in fedoramagazine.org
- Test von heise.de
- Test von golem.de
- Test von derstandard.at
- Fedora auf distrowatch.com
Details zu btrfs, systemd-resolved und Swap on ZRAM
Hallo Herr Kofler,
wegen btrfs habe ich eine Frage. Redhat steht ja hinter Fedora und die hatten sich doch vor ca 2 (3?) Jahren von btrfs entfernt, mit der Begründung „instabil“. Durch Suse bin ich seit Jahren btrfs Nutzer und hatte bisher noch keine Probleme damit und kann das daher nicht nachvollziehen, den bis jetzt ist alles problemlos gelaufen.
Aber wieso setzt Fedora jetzt auf btrfs, weil das ja hiesse, das Redhat mit seiner nächsten Version dann standardmässig dieses nutzen würde. Mir ist nicht bekannt, das Redhat seine Meinung zu btrfs revidiert hat.
besten Dank für ihre Antwort.
Ich weiß es nicht. An sich agiert das Fedora-Team in einem gewissen Ausmaß unabhängig von Red Hat. Ich glaube eher nicht, dass RHEL 9 auf btrfs umsteigen wird.
Das von SUSE her bekannte Snapper funktioniert auch mit Fedora 33 & Btrfs. Eine Integration mit DNF gibt es mittels des Pakets „python3-dnf-plugin-snapper“.
openSUSE bietet mit dem Rollback basierend auf snapper/btrfs das Nonplusultra an Flexibilität und Wartbarkeit. Benutzer sollten sich allerdings mit der vollautomatischen Wartung vertraut machen: https://forums.opensuse.org/showthread.php/547704-Cleanuing-up-leftover-snapshots?p=2986882#post2986882
Komplex ist btrfs nur für diejenigen, die meinen btrfs müsse so funktionieren wie sie sich es vorstellen und die Dokumentation ignorieren.
Ganz hervorragend funktioniert das Gespann networkd/resolved Mit den Herstellerimplementationen des Netzwerks hatte ich keine so guten Erfahrungen gemacht. Um so besser waren die mit systemd: https://en.opensuse.org/Network_Management_With_Systemd