Fedora 33

In Fedora 33 gibt es abseits der üblichen Versions-Updates drei vier grundlegende Neuerungen:

  • Als minimaler Texteditor ist nano vorinstalliert, nicht vim. Persönlich empfinde ich das als großen Fortschritt. Alle vi-Freunde müssen eben dnf install vim ausführen (so wie ich nach jeder Linux-Installation dnf/apt install joe ausführe, damit mir der Mini-Emacs jmacs zur Verfügung steht).

  • Das Defaultdateisystem für die Desktop-Version von Fedora lautet nun btrfs und nicht mehr ext4. (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.

Bei der Installation gibt es nicht viel einzustellen

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

Details zu btrfs, systemd-resolved und Swap on ZRAM

4 Gedanken zu „Fedora 33“

  1. 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.

    1. 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.

  2. 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“.

  3. 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

Kommentare sind geschlossen.