CleanPress

Schlagwort: Btrfs

  • Bcachefs erneut zur Überprüfung eingereicht

    Bcachefs erneut zur Überprüfung eingereicht

    Kent Overstreet, Entwickler des Copy-on-Write (COW)-Dateisystems Bcachefs hat seine aktuellen Patches zur Überprüfung bei den Kernel-Entwicklern eingereicht. Overstreet hält Bcachefs für reif für eine Aufnahme in den Kernel. Deshalb hat er seinen Review-Wunsch gleich als Pull-Request eingereicht, im Fall, dass die Kernel-Entwickler keine Einwände mehr haben sollten.

    Erstmals 2015 vorgestellt

    Overstreet stellte sein Dateisystem erstmals 2015 auf lklm.org vor, nachdem er bereits mehrere Jahre daran gearbeitet hatte. Entstanden war die Idee aus dem seit Linux 3.10 im Kernel integrierten und ebenfalls von Overstreet geschriebenen Gerätetreiber bcache, der, mit den damals aufkommenden SSDs im Blick, die Möglichkeit bietet, langsame Block-Devices wie Festplatten mithilfe schnellerer Block-Devices wie SSDs zu cachen. Somit erklärt sich der Name, der für block device cache steht.

    Robust und zuverlässig

    Overstreet erkannte, dass bcache bereits viele Grundelemente eines Dateisystems hat und beschloss, es zu einem solchen auszubauen. Dies dauerte allerdings länger als erwartet. Das definierte Entwicklungsziel ist, mit Ext4 und XFS gleichzuziehen, was Leistung und Zuverlässigkeit betrifft, aber mit den zusätzlichen Eigenschaften von Btrfs und ZFS. Dazu zählen COW, Prüfsummen für Daten und Metadaten, Caching, Kompression, Verschlüsselung und Snapshots. Dabei soll aber immer »Robustheit und Zuverlässigkeit vor Features und Hype« stehen.

    Zweiter Anlauf

    Vor rund 18 Monaten begann Overstreet eine Patch-Serie einzureichen, von der er glaubte, sie sei ausreichend stabil und fehlerfrei für die Aufnahme in den Mainline-Kernel. Linus Torvalds sah das anders und kritisierte die Patches sowohl inhaltlich als auch von der Form her. Jetzt macht Overstreet einen weiteren Anlauf, der aber selbst, wenn es keine Beanstandungen mehr geben sollte, wegen der Feiertage für Linux 5.11 vermutlich zu spät kommt. Die Chancen für eine Aufnahme im Jahr 2021 stehen aber nicht schlecht, was zur weiteren Reifung beitragen würde.

    Wird Bcachefs in den Kernel aufgenommen, so kann der Gerätetreiber bcache entfallen. Overstreet hofft, Btrfs bei Zuverlässigkeit und Geschwindigkeit überholen zu können. Ein Vorteil gegenüber Btrfs ist bereits jetzt die Möglichkeit, es als Cache einzusetzen, die Btrfs offiziell nicht bietet. Weitere technische Details bietet ein Artikel auf LWN.

  • Was kann Btrfs bei Fedora 33?

    Fedora 33 und Ubuntu 20.10 erscheinen innerhalb weniger Tage in der dritten Oktoberwoche. Was haben die beiden außer GNOME 3.38 noch gemeinsam? Beide können standardmäßig Snapshots erstellen. Bei Ubuntu geschieht das mit ZFS und ist bereits teilweise automatisiert, es fehlt noch die grafische Umsetzung.

    Vereinfachtes Storage-System

    Fedora 33 setzt erstmals bei Neuinstallationen standardmäßig auf das nicht unumstrittene Btrfs als Dateisystem. Was hat die Entwickler zu diesem Schritt bewogen? Btrfs bei Fedora soll dem Anwender hauptsächlich die Verwaltung des Storage-Systems erleichtern. Btrfs bringt im Gegensatz zu einem reinen Dateisystem wie Ext4 viel zusätzliche Funktionalität mit, die beispielsweise den Logical-Volume-Manager LVM überflüssig machen.

    Transparente Komprimierung

    Zudem bringt es bei Fedora 33 transparente Komprimierung von Dateien per Zstd. Die Komprimierung kann per Subvolume einzeln eingeschaltet werden, das System entscheidet dann, welche Dateien davon profitieren und wann sie zu dekomprimieren sind. Das spart nicht nur Platz, sondern verringert auch die write amplification bei SSDs. Per chattr + c /pfad lassen sich auch einzelne Dateien komprimieren. Die Datenintegrität wird durch Checksummen sichergestellt.

    Nur 2 Subvolumes

    Die Entwickler lassen bei der Einführung von Btrfs Vorsicht walten, die initiale Implementierung soll dazu dienen, dass sich Anwender mit den neuen Funktionen vertraut machen. Es gibt eingangs lediglich die beiden Subvolumes root und home. Zum Vergleich: openSUSE erstellt bereits bei der Installation ein gutes Dutzend davon, was Neueinsteiger beim butter– oder auch betterfs, wie Btrfs auch benannt wird, schnell verwirren kann. Eine Dokumentation, die die Handhabung der neuen Funktionen erläutert, ist gerade im Entstehen.

    Snapshots vorerst nur per Terminal

    Einen weiteren Vorteil von Btrfs, die zurückrollbaren Snapshots hebt sich Fedora für ein späteres Release auf. Es gab zwar einen Änderungsvorschlag für Fedora 33, das bei openSUSE eingesetzte Tool Snapper für Snapshots so einzusetzen, dass jede Aktion des Paketmanagers dnf, die den Paketstatus ändert, automatisch die Erstellung eines Snapshots auslöst, aber der Vorschlag wurde für 33 nicht abgesegnet und ist auch noch nicht bei den geplanten Änderungen für Fedora 34 zu finden. Snapshots lassen sich derzeit also nur per Terminal erstellen und verwalten.

    Um Snapper so einzubinden, dass automatisch Snapshots erstellt werden, müssen Änderungen unter anderem im Paketmanager DNF, in Grub2, Initramfs und im Installer Anaconda vorgenommen werden. Nur so lässt sich beim Booten ein älterer Snapshot auswählen und davon starten.

  • Btrfs für Fedora 33 erhält interessante Optionen

    Fedora

    Die Arbeiten am für den 20. Oktober erwarteten Fedora 33 laufen auf vollen Touren. Dabei erhält unter anderem auch das Dateisystem Btrfs, das als Standard für alle Desktop-Ausgaben von Fedora 33 bestimmt wurde, neue Optionen.

    SSDs besser bereinigen

    So wird für SSDs neben dem mit dem derzeit aktuellen Fedora 32 als wöchentlichem Standard eingeführten TRIM-Befehl zur Markierung ungenutzter oder ungültiger Datenblöcke eine weitere Option zur Bereinigung der Datenträger angeboten. Der Fedora-Installer Anaconda soll einen neuen Schalter erhalten, der die Mount-Option
    discard=async     in die Datei /etc/fstab schreibt. Weitere diskutierte Methoden der Umsetzung sind Systemd-Units oder eine Udev-Regeln.

    TRIM und Discard

    Damit sollen SSDs, die hoher Belastung durch viele Schreib- und Löschzyklen unterliegen, wo das wöchentliche TRIM unter Umständen nicht ausreicht, besser bereinigt werden. Beide Methoden können gleichzeitig genutzt werden. Unklar ist derzeit noch, ob die Option Opt-in bleibt oder mit Fedora 34 standardmäßig gesetzt wird. Bei Facebook, wo Btrfs auf vielen Tausenden Servern läuft, wird die zusätzliche Option seit mehr als sechs Monaten ohne Regressionen eingesetzt.

    Komprimierung

    Bei einer weiteren Verbesserung geht es um Komprimierung per Btrfs. Diese spart Platz, reduziert die Write Amplification erheblich und erhöht somit die Lebensdauer des Flash-Speichers und in einigen Fällen auch die Leistung. Wie der Vorschlag umgesetzt wird, ist noch unklar. Vermutlich soll Zstd als Algorithmus Verwendung finden.

    Der Befehl chattr zum Setzen von Attributen für Dateien komprimiert mit dem Parameter -c automatisch, allerdings wird dann Zlib als Methode verwendet. Auch xattr käme zur Umsetzung in Frage. Fedora 33 verspricht jedenfalls, ein spannendes Release zu werden, sowohl was die Quantität als auch die Qualität der anstehenden Änderungen angeht.

    Spannendes Release

    Neben Btrfs als Standard-Dateisystem für alle Desktop-Varianten soll unter anderem zRAM für Swap gesetzt werden. Nano wird zum Standard-Editor und Dienste werden nach RPM-Aktionen neugestartet, wie dies APT bereits bei Debian Unstable tut.

  • Fedora berät über Btrfs als Standard-Dateisystem

    Fedora 33

    Seit einigen Tagen wird auf der Fedora Mailingliste ein Vorschlag diskutiert, mit dem für den Herbst erwarteten Fedora 33 Btrfs anstatt Ext4 als Standard-Dateisystem für die Fedora Workstation auszuliefern. Der Vorschlag wird nicht nur von langjährigen Fedora-Entwicklern wie Neil Gupta unterstützt, sondern auch von Btrfs-Maintainer Josef Bacik, der bei Facebook mit für Btrfs verantwortlich ist.

    Besser als sein Ruf

    Btrfs hat über die Jahre einen schlechten Ruf erworben. Es gab viele Probleme, die teils sogar mit Datenverlust einhergingen. Auch die fehlenden oder qualitativ schlechten Tools zur Problemanalyse und -behebung standen in der Kritik. Damit hat die einst als das kommende neue Standard-Dateisystem für Linux gehandelte Software viel von ihrem Renommee verloren.

    Seit Jahren im Einsatz

    Andererseits setzen openSUSE und SUSE das Dateisystem seit 2014 als Standard ein. Bei Facebook laufen Millionen Server mit einfachen Consumer-SSDs auf Btrfs. NAS-Distributionen wie Rockstor oder die Software von NAS-Hersteller Synology und einiger anderer setzen ebenfalls darauf.

    Ist der Ruf erst ruiniert…

    Eines der Probleme von Btrfs heute ist, dass ein angekratzter Ruf schwer zu revidieren ist, da helfen die gebetsmühlenartig wiederholten Berichte aus der Vergangenheit nicht. Dabei ist das Dateisystem laut Meinung vieler Entwickler heute um einiges besser als sein Ruf. Lediglich bei RAID5/6 gibt es noch Probleme, die aber zum Teil auch an der Implementierung dieses RAID-Levels liegen.

    Btrfs hat gegenüber dem derzeit bei Fedora genutzten Standard LVM + ext4 unbestreitbare Vorteile, allen voran native Subvolumes, Crc32c-gestützte Checksummen, transparente Kompression, Deduplikation und Resizing. Hinzu kommen Snapshots, die auf einzelne Subvolumes begrenzt werden können.

    Erster Versuch

    Fedora und Red Hat haben eine wechselvolle Geschichte, wenn es um das Next-Gen-Dateisystem geht. Bereits 2011 sollte Btrfs mit Fedora 16 zum Standard werden, jedoch fand dies auch mit den Ausgaben 17 und 18 keine Mehrheit in Fedoras Steuerungskomitee FESCo.

    Bei Red Hat wurde das unter RHEL 6 als technische Vorschau eingeführte Dateisystem Btrfs nicht in RHEL 7 übernommen, sondern von XFS ersetzt. Gleichzeitig startete Red Hat auf dessen Basis die Entwicklung von Stratis als neuem Storage-System.

    Als Gründe für den Umstieg gab Red Hat den berüchtigten »out of disk space« Fehler an, der es bereits in die offizielle FAQ geschafft hatte, sowie Probleme mit den Balance Filtern für Metadaten. Zudem soll OverlayFS nach einer Auswertung bei Red Hat schneller beim Erstellen und Entfernen von Docker-Containern sein als Btrfs.

    Kein Entwickler an Bord

    Red Hats Entscheidung ist nachvollziehbar, wenn man weiß, dass mit Josef Bacik bereits 2012 der einzige Btrfs-Entwickler auf Red Hats Besoldungsliste das Unternehmen verließ, um 2013 zusammen mit Btrfs-Vater Chris Mason bei Facebook anzuheuern, wo seitdem der Schwerpunkt der Weiterentwicklung liegt.

    Die Diskussion bei Fedora beginnt gerade erst und es wird spannend zu sehen, ob Fedora diesen Schritt für das im Oktober erwartete Fedora 33 geht, obwohl Red Hat Btrfs 2017 den Laufpass gegeben hat.

  • OpenSUSE Leap 15 steht vor der Tür

     

    openSUSE Leap 15
    Logo: openSUSE | Lizenz: GFDL 1.2

    Am 25. Mai soll openSUSE Leap 15 offiziell freigegeben werden. Die Distribution steht im bereits seit einem Vierteljahrhundert rotierenden SUSE-Produktuniversum in der Mitte zwischen  dem Rolling-Release Tumbleweed und der kommerziellen Ausgabe SUSE Linux Enterprise Server (SLES) und speist sich aus beiden. Im Februar hatte ich bereits auf einen Blick auf einen Snapshot im Betas-Status geworfen. Heute geht es eher um ein herausragendes Merkmal des neuen openSUSE Leap – die transaktionalen Updates.

    Neue Herausforderungen

    In den letzten Jahren trugen die Weiterentwicklung des Linux-Kernels und die Entstehung neuer Paketformate und Container dazu bei, dass sich vielerorts die Art und Weise, wie Software und deren Konglomerierung zu Distributionen aktualisiert wird, veränderte. Im Internet der Dinge (IoT), wo Linux auf eingebetteten Geräten läuft, sind Updates einerseits enorm wichtig, andererseits aber sehr schwierig. Sie müssen zentralisiert und automatisiert durchgeführt und kontrolliert werden. Geht dabei etwas schief, wäre bei herkömmlichen Methoden der Aktualisierung guter Rat teuer.

    Deswegen kommen dort und anderswo sogenannte atomare Updates, auch als transaktionale Updates bezeichnet, zum Einsatz. Dabei wird ein Update gebündelt, nicht ungleich einem Image vollzogen. Geht dabei etwas schief, wird das gesamte Update zurückgerollt und der Zustand vor dem Update wieder hergestellt. So aktualisiert etwa Canonical seine Snaps, die bereits in vielen Geräten des IoT werkeln.

    OSTree

    Auch die Container-Variante von Fedora, Atomic-Workstation, trägt diese Art der Aktualisierung bereits im Namen. Gerade arbeiten die Fedora-Entwickler daran, die Workstation-Ausgabe der Distribution im Rahmen des Projekts Silverblue transaktional zu gestalten. Den Update-Mechanismen liegt die Bibliothek libostree zugrunde, die zusammen mit einigen Kommandozeilentools als OSTree bezeichnet wird. Das Paketformat Flatpak bedient sich dieses Modells ebenso wie die gerade in Version 3.4 erschienene Endless OS. Dazu wurde bei Endless eigens ein  Updater geschrieben.

    Btrfs + Snapper + Zypper

    OpenSuse verfügt durch die Verwendung von Btrfs als Dateisystem und per Snapper kontrollierte Snapshots des Systems bereits seit längerem über ein ähnliches System, allerdings entkoppelt vom Aktualisierungsmechanismus der Distribution. Zu festgelegten Zeiten oder vor einem umfangreichen Update wird mit Snapper ein Snapshot erstellt, der eingespielt wird, falls das Update schiefgeht. Mit openSUSE Leap 15 wird dieses System nun direkt mit den Aktualisierungen verknüpft. Aus dem auf Tumbleweed basierenden Projekt Kubic, das der Entwicklung von Container-Technologien dient, stammt die Entwicklung, die künftig den Anwendern von openSUSE Leap alternativ transaktionale Updates bescheren wird.

    Dabei werden Aktualisierungen entweder in einer einzigen Transaktion oder gar nicht auf das System angewendet. Dies geschieht ohne Beeinflussung des laufenden Systems. Wenn ein Update fehlschlägt oder wenn das erfolgreiche Update als inkompatibel oder anderweitig fehlerhaft angesehen wird, kann es verworfen werden, um das System sofort wieder in seinen vorherigen Betriebszustand zu versetzen.

    Unberührt

    Transaktions-Updates berühren nie direkt das laufende System. Anstatt das aktuelle System zu patchen, erstellt das Transaktions-Update-Tool einen neuen Snapshot. Alle für das Update erforderlichen Operationen werden vorerst nur in diesem Snapshot ausgeführt. Am Ende des Updates wird bei erfolgreicher Aktualisierung ein abgeschlossener Snapshot als neuer Standard markiert. Diese Updates werden dann beim Neustart des Systems wirksam. Wenn die Aktualisierung nicht erfolgreich war, wird der Snapshot verworfen und keine Änderung am System vorgenommen.

    Wer die neue Technik bereits jetzt testen möchte, wählt bei der Installation von openSUSE Leap 15 im Tab »User Interface« die Option »Transactional Server«. Das Image der Beta-Version ist rund 3.6 GByte groß. Viel Spaß beim Testen.

  • Stratis – Red Hats neues Storage-System

    Stratis – Red Hats neues Storage-System

    Im August 2017 erklärte Red Hat seine vermutlich endgültige Abkehr vom Btrfs-Dateisystem. Bald darauf wurde klar, dass ein neu gestartetes Projekt zu Red Hats künftiger Speichertechnologie werden soll. Die Rede ist von Stratis, dass vor wenigen Tagen mit Fedora 28 erstmals vorgestellt wurde und für Fedora 29 eine erste stabile Version 1.0 anstrebt.  Stratis soll eine ähnliche Funktionalität wie ZFS und Btrfs bieten, allerdings basierend auf einem hybriden Modell. Da ZFS aus lizenzrechtlicher Sicht für Red Hat nicht infrage kommt und Btrfs eigene Probleme im Zusammenspiel mit Docker zeigt, entschied sich Red Hat zu dieser partiellen Neuentwicklung, die vor rund einem Jahr in einem White-Paper (PDF) vom Hauptentwickler Andy Grover erstmals beschrieben wurde.

    Nicht neu erfunden

    Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern aus bestehenden Komponenten eine Lösung bauen, die dem Anwender eine gut integrierte Lösung mit konsistenter Konfiguration bietet. Hauptentwickler Andy Grover beschreibt es in dem Papier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut und in Rust und Python umgesetzt wird. Stratis soll dabei nicht nur den Geschäftskunden von Red Hat die Konfiguration und Pflege riesiger Disk-Arrays erleichtern, sondern auch dem Desktop-Anwender mit nur einer SSD.

    Vereinfachend

    Stratis zielt darauf ab, drei Dinge einfacher zu machen: die anfängliche Konfiguration des Speichers, spätere Änderungen und die Verwendung erweiterter Speicherfunktionen wie Snapshots, Thin Provisioning und sogar Tiering. Es bedient sich dabei des Konzepts des Storage-Pools, bei dem eine oder mehrere Disks zunächst unspezifiziert zusammengefasst werden, um später mehr Flexibilität zu bieten als dies feste Partitionen tun. Im Gegensatz zu LVM wird, ähnlich wie bei einem Virtual-Machine-File-System (VMF) das Dateisystem mit dem Pool verschmolzen, was bei Btrfs als Subvolume bekannt ist. Bei Stratis heißt es einfach Filesystem, dessen einzige Größenbeschränkung die Größe des Pools darstellt.

    Was unterscheidet Stratis von ZFS, Btrfs und LVM?

    Anstatt ganz von vorne zu beginnen versuchen die Entwickler bei Stratis von den Fehlern der Vorgänger zu lernen und bestehende Komponenten zu nutzen. Das Device-Mapper-Framework (DM), dessen sich auch LVM bedient um blockorientierten Geräten Funktionen wie RAID und Thin Provisioning  zur Verfügung zu stellen arbeitet hierfür zusammen mit dem XFS-Dateisystem. Von ZFS wurde der kommandozeilenbasierte Ansatz übernommen sowie die Art und Weise, wie Festplatten zu einem Pool hinzugefügt oder ersetzt werden.

    Bei Btrfs wurden Anleihen beim Konzept der Dateisystem-Snapshots und der Redundanz gemacht. Am weitesten reicht die Verwandtschaft jedoch bei LVM, da beide auf DM als grundlegende Komponente setzen. Stratis soll aber einfacher zu handhaben sein, ohne allzu viel von der breiten Funktionalität von LVM vermissen zu lassen. Somit wird Stratis eine weitere Möglichkeit bieten, einen Storage-Pool zu konfigurieren und zu verwalten.

    Zeitplan offen

    Mit Version 1.0 soll Stratis Snapshots beherrschen, für Stratis 2.0 ist die Integration von RAID und Write-Through-Caching geplant. Mit Version 3.0 soll die Funktionsparität mit ZFS erreicht sein. Abgesehen von Stratis 1.0, das mit Fedora 29 im Oktober erwartet wird, ist noch kein weiterer Zeitplan bekannt.