Fragen zu btrfs

[Kobold]

Hi Andreas,
Erstmal danke für den Guide.

@andreas85

Wenn @home ein eigenes Subvolume ist, werden die Snapshots von @ und @home getrennt durchgeführt.

@andreas85

Ein Backup des Volume erfasst alle Subvolumes und Snapshots

Ich verliere hier etwas die übersicht.

Gilt das dann auch für Snapshots die in Timeshift erstellt wurden?

Während bei Timeshift EXT4 (Rsync) standardmäßig nur / (root) gesichert wird.
Wenn /home eine extra partition ist. Wäre das jetzt mit BTRFS und /home (subpartition) jetzt anders geregelt?

@andreas85

Wenn @home ein eigenes Subvolume ist, werden die Snapshots von @ und @home getrennt durchgeführt. Bei einem System-Rollback auf den Stand von vor 4 Wochen verändern sich die Daten unter /home nicht, sonder alle unter /home/* inzwischen gemachten Veränderungen bleiben erhalten.

Das ist ja schon sehr speziell das jetzt: / und /home
jetzt plötzlich zu: @ und @home werden.

Zusammen mit den ganzen anderen Guides um BTRFS und was man dort alles beachten muß, gegen über EXT4… ist BTRFS für mich weiterhin ein Monster und hat für mich mit einem Benutzerfreundlichen Dateisystem nichts mehr zu tun.

Vielleicht liegt es aber auch nur an mir das ich mit diesen Teils großen und langen BTRFS Guides. Irgendwie kaum interesse habe mich mit auseinander zu setzen, weil ich denke das es einen schon sprich wörtlich erschlägt an informationen.

Da du ja schon ein langjähriger benutzer von BTRFS bist, würde mich interessieren ob du denkst das sich diese ganzen BTRFS Regeln die es aktuell zu beachten gibt… das diese nach der Zeit bei weiterer BTRFS Entwicklung noch zurückgehen werden oder ob sogar neue Regeln hinzukommen könnten?

[megavolt]

Hi @Kobold

ist zwar an Andreas gerichtet, aber ich versuche mal darauf zu antworten:

@Kobold

Während bei Timeshift EXT4 (Rsync) standardmäßig nur / (root) gesichert wird.
Wenn /home eine extra partition ist. Wäre das jetzt mit BTRFS und /home (subpartition) jetzt anders geregelt?

Timeshift sichert auch bei BTRFS standardmäßig nur das Wurzelverzeichnis, was hier das Subvolume @ wäre. Ein Subvolume @home auf einer separaten Partition mit BTRFS wäre kein Standard für Timeshift. Hier würde Timeshift ein Problem haben. Generell wäre ein Snapshot technisch nur dann möglich, wenn es auf derselben Partition/Dateisystem liegt, deswegen würde das Snapshot auch nur auf der Partition liegen, wo sich @home befindet.

Stell es dir wie eine Schattenkopie unter Windows vor, nur eben mit ganzen Ordnern, nicht nur Dateien. So eine Schattenkopie ist ein Snapshot einer Datei. Das funktioniert auch nur auf derselben Partition und ist technisch bedingt so, um Speicherplatz und Ressourcen zu sparen und vor allem geht es schneller, als das Kopieren und Vergleichen.

@Kobold

Das ist ja schon sehr speziell das jetzt: / und /home
jetzt plötzlich zu: @ und @home werden.

Stell dir einfach mal vor, @ und @home sind wie Partition in Gparted, aber innerhalb des BTRFS Dateisystems, dynamisch und sehen aus wie Ordner. Jedes Subvolume/Snapshot hat eine eigene ID und UUID:

sudo btrfs subvolume list -au /

Es gibt da eine Hierarchie, ein FSTREE, was auch ein Wurzelverzeichnis ist, was der klassischen Partitionstabelle (MSDOS/GPT) ähnlich ist, aber man kann auch normale Ordner anlegen und Subvolumes/Snapshots beliebig anlegen, auch innerhalb von Subvolumes.

Wenn du BTRFS einhängst, ohne ein Subvolumen zu erwähnen, wird immer das FSTREE angehängt, oder man gibt explizit subvol=/ als Option an.

@Kobold

Zusammen mit den ganzen anderen Guides um BTRFS und was man dort alles beachten muß, gegen über EXT4… ist BTRFS für mich weiterhin ein Monster und hat für mich mit einem Benutzerfreundlichen Dateisystem nichts mehr zu tun.

Klar kann man es so sehen. Andererseits ist es eine Frage der Innovation und Anpassung. BTRFS ist kein “Monster” - es ist anderes gedacht und konzipiert, sodass es den modernen Bedürfnissen ohne Hacks oder zusätzliche Programme entsprechen, die bei ext4 z. B. nötig wären.

Für mich ist es benutzerfreundlich, da viele externe Werkzeuge wegfallen:

• Snapshots ersetzt rsync oder borg (zeitaufwändig).
• Subvolumes ersetzen die statischen Partitionen.
• Prüfsummen der Daten integriert, statt eigene Prüfsummen erstellen (zeitaufwändig).
• Komprimierung der Daten integriert statt extern komprimieren zu müssen über Archive (zeitaufwändig).
• Deduplizierung der Daten integriert, statt fdupes/rmlint etc. laufen zu lassen (zeitaufwändig).

@Kobold

Vielleicht liegt es aber auch nur an mir das ich mit diesen Teils großen und langen BTRFS Guides. Irgendwie kaum interesse habe mich mit auseinander zu setzen, weil ich denke das es einen schon sprich wörtlich erschlägt an informationen.

Keiner zwingt dich dazu. Bleib einfach bei deinen Werkzeugen, die du kennst. Neue Technik erfordert immer neu zudenken. Wenn dir das schwerfällt und du bei deinen Gewohnheiten bleiben willst, weil es für dich funktioniert. Dann ist es so, oder lass dir einfach Zeit.

@Kobold

würde mich interessieren ob du denkst das sich diese ganzen BTRFS Regeln die es aktuell zu beachten gibt…

Verstehe ich nicht. Die “Regeln”, wenn man es so nennen will, sind für diejenigen da, die das brauchen, wenn sie nicht verstehen, dass diese neue Architektur anders ist und auch anders zu behandeln ist. Ist genauso wie wenn man eine Regel aufstellen würde, dass man ein Elektroauto nicht mit Diesel betanken sollte, oder Elektroautos keine Kupplung haben und viele diese Gewohnheit nicht ablegen können und genau diese geliebte Kupplung vermissen. Keiner würde hier behaupten, dass ein Elektroauto ein “Monster” wäre und man soviel beachten müsste.

Ich denke nicht, dass neue “Regeln” dazu kommen werden, da das Dateisystem an sich fertig ist. Es wird einfach weiter optimiert und gefundene Fehler werden behoben. Theoretisch könnte noch dateibasierte Verschlüsslung, wie bei ext4 dazu kommen, aber ich denke der Bedarf dafür ist minimal bis unpopulär, da eine komplette Verschlüsselung sinnvoller ist.

[Vidar]

@andreas85

noatime

@andreas85 : Eine Frage zu noatime:

In der standardmäßigen Btrfs-Installation von Manjaro ist es in der /etc/fstab für die Subvolumes nicht eingetragen. Warum, wenn es doch so sinnvoll ist?

Edit: Der Sinn und die Funktion der noatime-Funktion sind mir schon von EndeavourOS her bekannt.

[Nachlese]

Ist keine Standardeinstellung, weder hier noch in EOS oder Arch oder irgendwo anders -
und auch egal, welches Dateisystem -
weil manche Programme (ältere, heute seltene) auf die atime zur korrekten Funktion angewiesen sind.
Die würden dann unerwarteterweise standardmäßig nicht mehr funktionieren.

Die atime ist ein feature, was man nur ganz bewußt abschalten sollte - damit man sich später im Fall des Falles nicht wundert, weil man sich hoffentlich erinnert, das getan zu haben.

[megavolt]

@Vidar

In der standardmäßigen Btrfs-Installation von Manjaro ist es in der /etc/fstab für die Subvolumes nicht eingetragen. Warum, wenn es doch so sinnvoll ist?

Aus Gründen der Kompatibilität. relatime ist ja Standard und wird auch verwendet. Alle 24 Stunden (& später) oder bei Modifizierung wird die Zugriffszeit aktualisiert. So können Programme wie Dovcot, Postfix oder Mutt, die ein Maildir-Format verwenden, weiter problemlos funktionieren, wenn auch ein wenig ungenauer, dafür hat man aber bessere Performance. Oder auch mod_disk_cache bei Apache. Also eher ein Kompromiss. Wenn man sicher ist, solche Anwendungsfälle nicht zu haben, kann man selbst ausschalten, wenn einem dieser kleine Performance-Gewinn wichtig ist.

[Vidar]

Danke @megavolt

[Kobold]

@Megavolt danke für deine ausführliche Erklärung

@megavolt

Verstehe ich nicht. Die “Regeln”, wenn man es so nennen will, sind für diejenigen da, die das brauchen, wenn sie nicht verstehen, dass diese neue Architektur anders ist und auch anders zu behandeln ist. Ist genauso wie wenn man eine Regel aufstellen würde, dass man ein Elektroauto nicht mit Diesel betanken sollte

Wegen Regeln die möglicherweise wegfallen: Wäre da zum Beispiel eine in Zukunft mögliche automatisierung. Das man seinen Datenträger gar nicht mehr als 80% füllen darf wenn BTRFS genutzt wird, ob das durch ein script geregelt wird/werden könnte oder mit anderen Werkzeugen das lass ich mal jetzt offen.

BTRFS hat ja anscheinend noch genug Achillesfersen, wo man sich verkalkulieren kann. Da bräuchte man zumindest einige Pop Up’s/Stop Schilder mit Hinweisen das man da vielleicht grade was gefährliches macht.

Ich halte es weiterhin für bedenklich das Manjaro out of the box mit BTRFS vorinstalliert wird. Zumindest sollte man dann nicht mehr Marketing Mäßig mit Benutzerfreundlichkeit werben (was Manjaro ja offensichtlich weiterhin tut). Wenn sich eine gewisse Benutzerfreundlichkeit sich unter BTRFS nicht vereinbaren lässt, sollte man auch dazu stehen.

Ich denke das mit dieser Entscheidung hier sehr viele unerfahrene Manjaro Linux User vor dem Kopf gestoßen werden, die dann noch ihr Blaues wunder erleben werden. Denn genau diese Leute klicken auf eine Auto Installation, weil sie eben keine ahnung haben und die Installation möglichst simple sein soll.

[megavolt]

@Kobold

Wegen Regeln die möglicherweise wegfallen: Wäre da zum Beispiel eine in Zukunft mögliche automatisierung. Das man seinen Datenträger gar nicht mehr als 80% füllen darf wenn BTRFS genutzt wird, ob das durch ein script geregelt wird/werden könnte oder mit anderen Werkzeugen das lass ich mal jetzt offen.

Nagut, aber ext4 wird dann bei 90 % kritisch, mit ähnlichem Phänomen: kein Zugriff, kein Bootvorgang. Das ändert sich nicht mit BTRFS.

@Kobold

BTRFS hat ja anscheinend noch genug Achillesfersen, wo man sich verkalkulieren kann. Da bräuchte man zumindest einige Pop Up’s/Stop Schilder mit Hinweisen das man da vielleicht grade was gefährliches macht.

Wo? Der Speicherplatz sind “genug Achillesfersen”?

@Kobold

Ich halte es weiterhin für bedenklich das Manjaro out of the box mit BTRFS vorinstalliert wird. Zumindest sollte man dann nicht mehr Marketing Mäßig mit Benutzerfreundlichkeit werben (was Manjaro ja offensichtlich weiterhin tut). Wenn sich eine gewisse Benutzerfreundlichkeit sich unter BTRFS nicht vereinbaren lässt, sollte man auch dazu stehen.

Es wird auch nicht mehr als “benutzerfreundlich” beworben. Siehe: https://manjaro.org/

Manjaro Linux Empowering People and Organizations

Taking the raw power and flexibility of Arch Linux and making it more accessible for a greater audience.

Manjaro Linux stärkt Menschen und Organisationen

Die rohe Leistung und Flexibilität von Arch Linux nutzen und einem größeren Publikum zugänglich machen.

@Kobold

Ich denke das mit dieser Entscheidung hier sehr viele unerfahrene Manjaro Linux User vor dem Kopf gestoßen werden, die dann noch ihr Blaues wunder erleben werden. Denn genau diese Leute klicken auf eine Auto Installation, weil sie eben keine ahnung haben und die Installation möglichst simple sein soll.

Gut möglich, aber sie haben eben die Auswahl. btrFS ist halt de facto das nächste Standard-Dateisystem nach extFS. Und btrFS als Standard festzulegen, ist nur ein logischer Schritt.

[andreas85]

@Kobold

Gilt das dann auch für Snapshots die in Timeshift erstellt wurden?

Ja

@Kobold

Zusammen mit den ganzen anderen Guides um BTRFS und was man dort alles beachten muß, gegen über EXT4… ist BTRFS für mich weiterhin ein Monster

Bei btrfs ist halt der volume-manager mit drin, was bei ext4 extra Arbeit war. Aber das braucht die meisten Nutzer nicht zu kümmern. Der Grund ist aufgeführt damit jeder eine informierte Entscheidung treffen kann .

@Kobold

ob du denkst das sich diese ganzen BTRFS Regeln die es aktuell zu beachten gibt… das diese nach der Zeit bei weiterer BTRFS Entwicklung noch zurückgehen werden oder ob sogar neue Regeln hinzukommen könnten?

Btrfs ist schon “erwachsen”. Die Regeln werden sich nur noch geringfügig ändern.

• Btrfs hat eigene Regeln.
• ext3/ext4 hat eigene Regeln.
• FAT hat eigene Regeln.

Mit manchen davon ist man seit 40 Jahren vertraut.

• Wenn du einen Datenträgfer mit FAT hart unmountest (rausziehst) ist er meist kaputt (Dateisystem beschädigt, meist nicht reparierbar). Das ist so eine Regel. Niemand scheint sich mehr daran zu stören.
• Aber diese Regel gibt es für BTRFS nicht. Es kann halt sein dass nicht alle Daten da sind, weil sie noch nicht geschrieben wurden. Das Dateisystem selbst ist aber nahezu unkaputbar.

@Vidar

In der standardmäßigen Btrfs-Installation von Manjaro ist es in der /etc/fstab für die Subvolumes nicht eingetragen. Warum, wenn es doch so sinnvoll ist?

Für dich und die meisten anderen ist noatime sinnvoll. Aber als default ist es riskant. (wird im Link erklärt)

@Kobold

Wäre da zum Beispiel eine in Zukunft mögliche automatisierung. Das man seinen Datenträger gar nicht mehr als 80% füllen darf wenn BTRFS genutzt wird,

Seinen Datenträger zu füllen kann nicht durch ein script verhindert werden.

Der User macht was er will.

Die 80% sind waren eine Empfehlung. (Das ist eine Frage der Gesundheit ) (Empfehlung ist inzwischen angehoben auf 85-90%)

• Wer sich bei btrfs daran hält braucht meist nie ein balance zu machen. btrfs selbst kümmert sich dann gut um das Dateisystem. Dazu ist aber etwas freier Platz erforderlich.
• Meist reichen einige wenige GB damit btrfs keine Probleme macht.
• Aber wie bei anderen Dateisystemen auch endest du mit viel Fragmentierung wenn du am Rand der Klippe lebst.
• Jedes Update spielt einige GB an Daten ein. Du möchtest doch nicht dass dir währenddessen der Platz ausgeht ? (auch nicht mit ext4)

Ein wirkliches Risiko sind die Snapshots, wenn du damit rumspielst, sie aber nicht automatisiert einrichtest. Dann geht dir der Platz nach einiger Zeit aus. Aber das ist mit jedem Dateisystem so, das Snapshots unterstützt.

@Kobold

BTRFS hat ja anscheinend noch genug Achillesfersen, wo man sich verkalkulieren kann.

Das hat ext4 und FAT ebenso. Auch andere Dateisysteme (von NTFS ganz zu schweigen). Mach mal eine ext3 Systempartition / voll und dann versuch zu booten. Dabei ist es dann nutzlos dass du auf anderen Partitionen noch Platz frei hast.

Btrfs ist genauso benutzerfreundlich wie ext3/4.

Wir setzen btrfs auf 30k Geräten ein. Und die Benutzer merken nix davon weil btrfs stabil läuft. Auch wenn einige das Gerät hart ausschalten passiert nix schlimmes. (Wir machen das Dateisystem meist nicht zu 100% voll. Aber selbst das ist durch einen admin reparierbar)

[Nachlese]

Bei ext2/3/4 werden ja - mit der standardmäßigen Dateisystemerstellung - 5% für root reserviert.
Was in den meißten heutigen Fällen viel zu viel und Verschwendung ist.
Ein “normaler” Benutzer schafft es also gar nicht, das Dateisystem vollständig voll zu machen, auch nicht aus Versehen.

Deshalb passe ich das immer auf 1% oder sogar 0% an nach der Erstellung oder Installation.

Kann man so einen “Sicherheitsmechanismus” auch in BTRFS realisieren?
Ein Monitor und eine Warnung, wenn es droht, eng zu werden?
Um Problemen dadurch vorbeugen zu können.

Wenn es einmal voll ist, wirds ja scheinbar etwas eklig.

Ich hab schon öfter das Dateisystem mit Nullen vollgeschrieben bis nix mehr reinpasste - und dann diese Datei(en) gelöscht, um Plattenabbilder so klein wie möglich zu halten.
Das ginge dann wohl mit BTRFS nicht?
… wäre wohl aber auch nicht nötig - da gibt’s halt andere Wege mit BTRFS …

[andreas85]

@Nachlese

Ich hab schon öfter das Dateisystem mit Nullen vollgeschrieben bis nix mehr reinpasste -

solang du in dem Zustand nicht versuchst zu booten geht auch nix schief.

@Nachlese

Kann man so einen “Sicherheitsmechanismus” auch in BTRFS realisieren?
Ein Monitor und eine Warnung, wenn es droht, eng zu werden?
Um Problemen dadurch vorbeugen zu können.

Ja, ist drin.

Deswegen brauchts auch keine Panik wenn btrfs “filesystem full” meldet. Aber was dann zu tun ist, ist halt anders als bei ext4.

@Nachlese

Ich hab schon öfter das Dateisystem mit Nullen vollgeschrieben bis nix mehr reinpasste

Versuch das mal wenn bei btrfs Kompression eingeschaltet ist

Und 80% 85% mit kompression (bei btrfs) sind immer noch mehr daten als 100% ohne (bei ext4). Also was soll der Geiz.

[Nachlese]

@andreas85

solang du in dem Zustand nicht versuchst zu booten geht auch nix schief.

Aha - danke für diese Info.
Das macht man ja auch (“normalerweise”) auch mit ext2/3/4 nicht.
Voll ist halt voll …

@andreas85

Deswegen brauchts auch keine Panik wenn btrfs “filesystem full” meldet. Aber was dann zu tun ist, ist halt anders als bei ext4.

Es meldet also.
… vor einem reboot oder erst danach?

Kriegt man es als Nutzer mit, bevor es u.U. “zu spät” ist?

@andreas85

Versuch das mal wenn bei btrfs Kompression eingeschaltet ist

Ja, ich weiß schon. Das hätte wohl keinen Effekt - jedefalls nicht den erhofften bzw. den, der auf anderen Dateisystemen eintreten würde.
Diese Methode scheidet dann bei BTRFS wohl komplett aus.

[Kobold]

@andreas85

Btrfs ist genauso benutzerfreundlich wie ext3/4.

Und wie ist das wenn man duplizierte dateien (backup) hat?

Hattest du da nicht mal hier im Forum etwas vor paar Wochen bei BTRFS angedeuted das es da zu problemen kommen kann?

@andreas85

Und die Benutzer merken nix davon weil btrfs stabil läuft.

Ja weil du die systeme für diese user als Admin wartest oder nicht? Das ist doch gar nicht der Fall, für die unerfahrenen Manjaro benutzer… die müssen doch selbst klar kommen.

[andreas85]

@Kobold

Ja weil du die systeme für diese user als Admin wartest oder nicht?

Nein, Wartung machen wir nur wenn ein Gerät eingeschickt wird. (was äußerst selten vorkommt, und fast nie wegen Problemen im Dateisystem)

@Kobold

Und wie ist das wenn man duplizierte dateien (backup) hat?

Duplizierte Dateien machen unter btrfs keine Probleme. Sie zählen aber nicht als “backup”, wenn sie auf dem selben device liegen.
Oft macht man das ja um ältere Konfigurationen oder Dateistände aufzubewahren (im Fall des Falles).
Das erübrigt sich wenn Snapshots verwendet werden, weil im Snapshot ALLE alten Dateistände lesbar im Zugriff sind. (Bis halt der Snapshot aufgelöst wird.) Der Platzverbrauch dafür entspricht gerade mal dem Volumen der geänderten Datei-teile. Und wenn Kompression eingeschaltet ist, dann ist all das zusammen kleiner als das gleiche Gesamtsystem auf ext4.

@Kobold

Hattest du da nicht mal hier im Forum etwas vor paar Wochen bei BTRFS angedeuted das es da zu problemen kommen kann?

Vielleicht hast du mich nur missverstanden. Wenn du einen Link hast, ändere ich den missverständlichen Text gerne.

[weingeist]

Jetzt habe ich auch mal eine Frage

btrfs – Sets the required modules to enable Btrfs for using multiple devices with Btrfs. You need to have btrfs-progs installed to use this. This hook is not required for using Btrfs on a single device where the filesystems hook suffices. Runs btrfs device scan to assemble a multi-device Btrfs root file system when udev hook or systemd hook is not present. The btrfs-progs package is required for this hook.

Also wenn ich alle meine Platten auf btrfs mache, brauche ich den Hook ? Bei einer einzelnen Platte nicht ?

Wenn man auf systemd umstellt braucht man ja den base hook nicht mehr wenn man ext4 verwendet. Mit btrfs brauchte man den base Hook noch zusätzlich.
Ist das immer noch so ?

[Nachlese]

@weingeist

Also wenn ich alle meine Platten auf btrfs mache, brauche ich den Hook ? Bei einer einzelnen Platte nicht ?

Nur wenn sich ein einziges Dateisystem über mehrere physische Geräte verteilt -
nicht wenn Du sowieso nur eine Platte hast (im Notebook …)

Es schadet aber sicher nicht, ihn trotzdem zu haben.

Hier ist, in Englisch, wo das herkommt:

mkinitcpio - ArchWiki

Link geht direkt zu der Tabelle.

[andreas85]

@weingeist

Also wenn ich alle meine Platten auf btrfs mache, brauche ich den Hook ? Bei einer einzelnen Platte nicht ?

Wenn du systemd einsetzt, gibt es diesen hook gar nicht mehr:

genauso wenig wie den base-hook.
Du brauchst ihn dann weder bei einem btrfs-volume das auf nur einem device(partition) sitzt, noch bei einem btrfs-volume das sich über mehrere devices(partitionen) erstreckt (RAID0). Nicht einmal für btrfs-RAID10

Wenn du noch busybox-init einsetzt, brauchst du den btrfs-hook nur wenn du btrfs RAID1 oder RAID10 einsetzt.

[andreas85]

@Kobold

Das man seinen Datenträger gar nicht mehr als 80% füllen darf wenn BTRFS genutzt wird,

Ich hab die Empfehlung im Wiki auf 85-90% angehoben (plus mindestens 5 GB freie Chunks). (Ab 95 % wirds kritisch)

Auch muss man bei manjaro beachten Platz für 1-2 Updates freizuhalten. Bei mir waren das auch schon mal deutlich mehr als 10 GB für ein Update.

Wenn man die Kompression eingeschaltet hat, bekommt man bei btrfs trotzdem zumindest 25% mehr Daten auf eine Partition als mit ext4 ohne in den Problembereich über 90% zu kommen.

[weingeist]

@andreas85

Wenn man die Kompression eingeschaltet hat, bekommt man bei btrfs trotzdem zumindest 25% mehr Daten auf eine Partition als

Wie sieht es eigentlich mit der Geschwindigkeit aus, mit und ohne Kompression ?

[andreas85]

@weingeist

Wie sieht es eigentlich mit der Geschwindigkeit aus, mit und ohne Kompression ?

Mit Kompression ist die Prozessorlast höher, dafür werden bei gleicher Geschwindigkeit des Datenträgers dann mehr Daten pro Zeiteinheit geliefert (oder geschrieben). Also je schneller der Prozessor ist, umso vorteilhafter wird Kompression.

Ob es schneller ist, hängt vermutlich vom Prozessor und der gewählten Kompressionsdichte ab (ich hab zstd:9 genommen)

Die Kompression braucht hauptsächlich beim Schreiben Zeit und Rechenleistung. ZSTD ist so optimiert, dass es beim lesen besonders wenig Zeit/Leistung braucht.