FAQ- und Sammelthreadübersicht / Linux Quatsch Thread

[pwnbert]

Wo ich nicht durchsehe ist, warum btrfs zstd (glaube) als compression verwendet und kein lz4 (das ist soo schnell beim zfs), schlecht ist compression nicht für Zeug, das sich komprimieren lässt...

 

[Shihatsu]

Nach zig Jahren Arch nativ möchte ich mal wider neu Aufsetzen und Überlege mal CachyOS auszuprobieren. Ich hoffe, falls es nervt wieder schnell zurück zu Arch konvertieren zu können.

Jetzt aber meine eigentliche Frage bzw. Gedanke. Ich habe bisher immer nur EXT4 verwendet und bin mit der Robustheit sehr zu frieden.

Ich habe eine Samsung 990 pro 2TB für Root, Swap(Hibernate) und Boot bzw. EFI. Dazu möchte ich 40% Overprovisioning machen.
Ich spiele mit dem Gedanken mal BTRFS auzuprobieren um Snapshots ziehen zu können. Einfach um mal sachen probieren und reverten zu können, gerade mit libvirt oder exotischen Kernel Modulen, Subvolumes für cache, tmp und .snapshot etc. sind mir bekannt. Ich mache mir eher sorgen um Robustheit und Stabilität. Hat wer schon etwas Erfashrung mit BTRFS, und ich meine nicht nur bei schönem Wetter?

Für /home, habe ich mir eine 8TB Samsung 9100pro gegönnt. Hier überlege ich mir XFS zu verwenden (ein Bekannter schwört drauf und will mich überreden). Hauptvorteil checksummen gegen die Bitfäule und dadurch meine Backups sauber halten. Wie sieht es hier mit Robustheit aus? Oder würdet ihr eher EXT4 verwenden?

Zusätzlich habe ich noch eine 1TB 990 pro die ich nicht mehr brauche. Die wollte ich mit F2FS formatieren und nach ~/.cache bindmounten um home clean zu halten. Gute Idee?

Dann habe ich noch eine 2 TB NVME pcie4 mit Innogrit Controller, die ich mit Ext4 as partiton für meine laufenden Container bzw. deren FS nutzen möchte.


Was habt ihr an Erfahrungen mit BTRFS, XFS und F2FS gemacht?

Warum 2 TB nur für Root? Das ist Perlen vor die Säue. Ich träume ja von nem kleinen optane für /root.
Was BTRFS angeht: Das ist der WEg. So einfach ist das. Warum? Weil ZFS ne doofe Lizenz hat. Solang das so ist, nimmt man eben das zweitbeste CoW, und das ist BTRFS. Grubsnapshots sind "der shit" - srsly, die hätten mich aus den letzten 2 dummen dingen die ich gemadcht habe rausgeholt. Habs aber jeweils "auf die harte Tour" gelöst wegen des Lernens

Gerade als Einzeldatenträger dürfte btrfs schon ganz brauchbar sein (für größere Storage-Sachen dann vllt. doch (open)ZFS).

Dies

Ich habe jetzt Root auf BTRFS und boot so konfiguriert, dass ich immer die letzten beiden Kernelversionen booten kann. Bei jedem Kernelupdate gibt es einen Snpashot. Funtioniert ganz gut. Die BTFRS settings habe ich im Prinzip von CachyOS übernommen.

Genau so macht mans.

Wo ich nicht durchsehe ist, warum btrfs zstd (glaube) als compression verwendet und kein lz4 (das ist soo schnell beim zfs), schlecht ist compression nicht für Zeug, das sich komprimieren lässt...

Man kann sich den Algorithmus aussuchen.

 

[Fallwrrk]

Ich hatte damals unter Arch meine Backups mit Btrfs gelöst. Snapshot von allen zu sichernden Subvolumes gemacht und dieses dann (versimpelt) mit "btrfs send | ssh nas btrfs restore" gesichert. Mit "btrfs send -p" und Angabe des letzten Snapshots lies sich das dann auch inkrementell lösen. Backups in ungelogen unter 200 ms, wenn sich nichts verändert hat. Denn Btrfs wusste, was sich geändert hat, und musste nicht den gesamten Verzeichnisbaum nach Änderungen absuchen, so wie klassische Backup-Tools es machen.

Der. Geilste. Shit. ÜBERHAUPT!

Hab nur damit aufgehört, weil jetzt auch ein Windows-Host gesichert werden sollte und Restic halt auf beidem funktioniert.

 

[pwnbert]

Man kann sich den Algorithmus aussuchen.

Jein, imho gibts kein LZ4 und die verfügbaren Algos sind alle meh und verfügen keinen richtigen "Schnellabbruch" (early abort) bei unkomprimierbaren Daten und sind im Vgl. zu LZ4 total lahm bzw. ressourcenlastig.

Imho kann btrfs nur ZSTD, LZO und ZLIB.
Kann sein, dass ich mich irre.

ZSTD ist default, weil angeblich gute Schnittmenge aus Kompression und Speed.
In meinen Augen ist das Schwachsinn und ich kann nicht verstehen, wie die Community bzw. die Entwickler zu dem Schluss gekommen sind.

Ich hab seinerzeit vor ca. 2 Jahren größere Tests am TrueNAS gemacht und dort LZ4 und verschiedene ZSTD Kompressionsstufen verglichen (gibt ein paar Ergebnisse irgendwo im HomeServer-Forum, hatte die letztens auch mal rausgesucht, weiss aber nimmer, wo das war).
Dabei kam raus, dass LZ4 quasi "gratis" ist, also keine zusätzliche CPU-Load erkennbar ist über dem Durchschnittsrauschen.
ZSTD hat auf Kompressionsstufen, auf denen es besser als LZ4 war massiv(!) CPU-Last verursacht (50% und mehr am 5750G / Zen 3 mit 8 flotten Cores) und dann auch entsprechend R/W gebremst.

Beim Compression-Ratio sieht es so aus, dass die meisten Daten (die Platz brauchen) überhaupt nicht komprimierbar sind, man sich die Sache also eigentlich schenken kann.
Videos/Fotos: nichts
Steam Library: nichts (mit Dark Souls 3 und Cyberpunk getestet)
AI-Models: nichts (mit .safetensors stable diffusion XL Models getestet)

Wo die Kompression was brachte, waren Backups vom OS (Win10) und "dazugehörigen Programmen" (was man halt so als Backup vom OS laufen lässt bei Win).
Dort waren die Unterschiede zwischen LZ4 und hohen ZSTD Varianten aber überschaubar. Bei gleicher Kompression war LZ4 dann aber immer noch schneller als ZSTD in geringer Stufe.


... soviel mal zur Speicherplatz-Einsparung und dessen Überlegungen.
Aus dem heraus würde ich sagen LZ4 oder nichts.



Allerdings habe ich von @gea gelernt (wenn ich das richtig verstanden habe), dass die Kompression bei ZFS ziemlich wichtig ist, da man damit diese typischen "Raid-5 mit falscher Plattenanzahl Effekte" vermeiden kann, das "leere Ende von CoW Blocks schrumpfen" kann und so Zeugs. Wenn ich das richtig verstehe, wird z.B. der Rest von einem 1mb Block (wenn man das so einstellt), in den eigentlich nur eine 100kb Datei geschrieben wird, per LZ4 klein gemacht und somit dieser Overhead vermieden - wenn ich das nicht falsch verstanden habe.

Dieser Absatz ist bitte mit Vorsicht zu lesen, so 100% verstehe ich das selbst nicht (daher auch die schlechte Wortwahl), aber diese Richtung dürfte das gehen.
Vielleicht hat @gea ja Zeit und Lust meinen Absatz hier richtig zu stellen.

Jetzt meine Frage aus diesem Blickwinkel heraus:
=> Ist die Compression für btrfs auch wichtig?

 

[gea]

Im Prinzip siehts ohne Compress so aus (bei ZFS und meines Wissens bei btrfs auch)

Die zu schreibenden Daten werden in Blöcke aufgeteilt, (ZFS recsize oder btrfs Einheiten). Diese Blöcke sind immer 2^n groß und müssen im Raid-Z (vergleichbare Raid Levels bei btrfs sind unstable, ist da also per se da nicht wichtig da man das nicht machen sollte) auf die Datenplatten im Raid-Z aufgeteilt werden. Ist die Plattenanzahl 2^n (2,4,8,..) so kann man den Datenblock ohne Verschnitt auf die Platten verteilen. Daher da die Empfehlung, z.B. ein Raid Z2 vdev (Datenplatten + Redundanz) aus 6 oder 10 Platten zu machen.

Aktiviert man compress, so werden diese Blöcke vor dem Schreiben komprimiert, haben also eine variable Größe. Es gibt also keine gleiche 2^n großen Teile. Man kann daher ein Raid-Z aus beliebig vielen Platten bauen und ist im Schnitt immer besser dran als ohne Compress und "golden Numbers of disks".

Den "kleinen" Verschnitt wenn ein Datenblock nicht ins Raster der 4k physical Platten passt, kann man ignorieren. Der Verschnitt bei nicht passender Plattenanzahl ohne compress kann 10% oder Mehr der Kapazität ausmachen.