News Linux News der Woche: Radeon für Loongson, Mesa 23.4.0, Brennpunkt Dateisysteme

[Krik]

@DoS007
Aus meiner Sicht ist das relativ einfach zu handhaben. Jedes Backup existiert 2x und dazu gibt es noch eine Liste von Hashes aller gesicherten Dateien. Somit habe ich von jeder Datei mindestens zwei echte Kopien (und damit Hashes) und einen Hash. Die lasse ich miteinander vergleichen und sollte einer der drei Hashes abweichen, weiß ich, wo ein Fehler aufgetreten ist und kann mich an die Behebung machen.

Das ist etwas, was das NAS in seiner Freizeit machen kann. Dafür muss ich nicht mein Hauptsystem mit einem vergleichsweise langsamen Dateisystem ausbremsen.

 

[Piktogramm]

@Piktogramm Es geht darum, die Sicherheit der Daten zu gewährleisten, die akutell auf der Platte sind (Datenintegrität ohne COW), z.B. Schutz vor Bitflips bei lang ausgeschalteten SSDs usw. und generell. Daher schon wünschenstwert und wenn ohne COW Performancegewinn vorhanen ist - super. Kenne aber kein solches Dateisystem.


Argument

Ah ok, wusste nicht, dass die Depulizierung Hauptverantwortlich für die RAM-Belastung ist bei ZFS.

Zu [1]: Also weniger TBW bei Defragmentierung auf SSDs meinst du?

Nehme an du nutzt ZFS? (Würde das nur bei einer Distribution verwenden, die das automatisch mitbringt und sich nicht vor den Lizenzrechten fürchtet wie der Linux-Kernel)

Die Checksummen sind kein Schutz vor Bitflips, sondern bieten die Chance Bitflips auf Ebene des Dateisystems zu erkennen. Eine Chance abseits von Backups an der Stelle noch etwas zu retten ergibt sich halt mit COW.
Wobei HDDs wie SSDs eigentlich intern bereits Fehlererkennung und bedingt Korrektur beherrschen sollten. Einzelne Bitflips sollten moderne Laufwerke also eher nicht verwirren und wenn es über die Fähigkeiten der Laufwerke hinaus geht, wird für ein Dateisystem auch nicht mehr viel zu retten sein.

Mal ganz abgesehen davon, dass Snapshots unglaublich praktisch sind. Automatische Snapshots vor jedem Update und automatisch bei Grub eingebunden. Analog beim eigenem Gebastel und generell zeitbasiert auf /home/ . Geht etwas schief wird halt vom Snaptshot gebootet, Irgend ein doofes Edit auf irgend eine Datei außerhalb einer Versionsverwaltung und der alte Zustand ist kinderleicht wiederherstellbar ohne externe Backaups anfassen zu müssen (Kann Windows mit Volume Shadow Copy auch, nur halt in absurd langsam..).

Ich hab auf meinen Rechnern keine Datenbank-Anwendung in Verwendung, soweit ich weiß. Klar, bei Server bzw. Business-Geräten ist das was anderes.

Sqlite oder Vergleichbares steckt in jedem modernen Betriebssystem + Anwendungen mit GUI und das garnichtmal in all zu kleinem Umfang.

So wie ich es verstanden habe, setzen die meisten Leute nur wegen der Snapshot- und Self-Healing-Features auf Btrfs. Ich persönlich finde, dass das zu schwache Argumente sind, da man im Alltagsgebrauch bis zu 75% Geschwindigkeitseinbruch gegenüber Ext4 und Xfs hat (siehe Phoronix)

Siehe oben, Snapshots sind geiler Scheiß!
Das Fahren von Benchmarks ist bei den aller meisten Systemen kein Alltag.
Wäre meine Aufgabe ein Datenbankcluster zu betreiben und da dem Mantra Performance, Performance, Performance zu folgen, wäre BTRFS auch nicht die Wahl um da die Datenbank drauf zu legen. Da würde ich tendenziell sowieso auf COW verzichten, die brauchbaren Datenbanklösungen implementieren COW bzw. Vergleichbares und datachecksumming ja selbst. Entsprechend wäre da auch ein ausentwickeltes BcacheFS raus.

Das ist etwas, was das NAS in seiner Freizeit machen kann. Dafür muss ich nicht mein Hauptsystem mit einem vergleichsweise langsamen Dateisystem ausbremsen.

Wenn eine flotte PCIe3 SSD steckt geht den meisten Leuten das Geld für CPU-Kerne aus, bevor irgend ein Dateisystem begrenzt.

 

[DoS007]

@Piktogramm Ich sehe schon, dass das praktisch ist. Nur die Sache ist, wenn einem die Geschwindigkeit auch bei günstigen und nicht so schnellen SSDs wichtig ist und man Backups macht und Dateningerität einem wichtig ist, dann wäre ein Dateisystem mit Inhaltsdateningerität ohne COW aber dafür schneller eine super Lösung (im Fall einer Integritätsverletzung aus Backup wiederherstellen).

Gibt es aber nicht ohne Nutzung von Layern drunter oder drüber (geordnet nach checksum; SquashFS ist readonly; man könnte höchstens irgendwie über LVM oder so noch was machen):

https://en.wikipedia.org/wiki/Comparison_of_file_systems

@Piktogramm @Krik : Nutzt ihr borg, restic oder kopia für backups oder so etwas gar nicht?

 

[Krik]

Ich habe mir ein bash-Skript geschrieben, dass auf rsync setzt. Das Skript wird von systemd regelmäßig ausgeführt.

 

[Piktogramm]

[...] ohne COW [...]
man könnte höchstens irgendwie über LVM oder so noch was machen

Ich sage es ja ungern, aber mit meiner Meinung, dass div. Features ohne COW wenig sinnvoll sind, stehe ich nicht allein da..

A Logical Volume Manager (LVM) logical volume snapshot is a copy-on-write technology that monitors changes to an existing volume’s data blocks so that when a write is made to one of the blocks, the block’s value at the snapshot time is copied to a snapshot volume. In this way, a point-in-time copy of the data is preserved until the snapshot volume is deleted.

https://documentation.suse.com/de-de/sles/12-SP5/html/SLES-all/cha-lvm-snapshots.html

Auch in deiner Liste, SquashFS ist read only und Ceph ist Objektstorage, alle anderen Dateisysteme mit Checksummen auf Data sind COW (bei Hammer steht es in der Dokumentation, aber nicht auf Wikipedia).

##############################

Backups:
Es läuft überall Borg außer auf dem Mietserver. Der schiebt zu meiner Schande manuell mittels btrfs send Images auf den Heimserver.

 

[dev/random]

Meine Hauptregel für Backup und Restore ist: Keep it simple
Also ein eigenes sh script über cron oder systemd laufen lassen, das je nach Art des Backup rsync oder tar nutzt. Und die benötligten Daten mit demselben Code auch ohne weitere Abhängigkeiten in anderen Umgebungen (inkl. busybox) wiederherstellen kann. Oder ich das ganze per Hand erledigen kann, da es noch leicht nachvollziehbar ist.
Wenn man auf offline-Backups setzt, sind manuelle Arbeitsschritte ohnehin nicht zu vermeiden. Die meisten Backup-Tools nehmen mir da nicht genug Arbeit ab, um sinnvoll zu sein (insbesonders beim Restore).

Nach 25 Jahren Erfahrung mit Linux habe ich privat keinen Bedarf nach "besseren" Lösungen.
Selbst lvm hat mir bisher mehr Aufwand als Vorteile gebracht. Daher kann ich auch gut auf bcachefs, btrfs usw. verzichten und nutze lieber die Vorteile von ext4.
Klar hatte ich auch schon Dateisystemfehler, meist aber in Zusammenhang mit Hardware-Defekten. Die bitflip-Erkennung bringt mir nichts, wenn der HDD headcrash gleich ganze Blöcke beschädigt, der SSD-Controller falsche Blöcke beschreibt oder der USB-Storage sich plötzlich disconnected.
Und wenn man Backups nicht vernachlässigt, gibt es eigentich keine kritischen Dateisystemfehler mehr

 

[Deinorius]

Die Geschwindigkeit spricht für sich.

Ich persönlich finde, dass das zu schwache Argumente sind, da man im Alltagsgebrauch bis zu 75% Geschwindigkeitseinbruch gegenüber Ext4 und Xfs hat (siehe Phoronix).

Die Phoronix Benchmarks sind völlig legitim (SQLite ist ja in Anwendungen vorhanden), aber wenn es um den Alltagsgebrauch geht, sind die kaum brauchbar. Es bräuchte andere Testformen, um auch jenen die Vor- und Nachteile näherzubringen. Eine einfache realitätsnahe, wenn auch zeitaufwendige, Möglichkeit wären Effizienzunterschiede mit Laptops aufzuzeigen, sofern der Benchmark die SSD stärker beansprucht.
Ansonsten sind Kompression, Snapshots (ich will nicht mehr ohne leben!) usw. einfach zu erklärende Vorteile. Dafür kann man z.B. auf dem Steam Deck /home auf btrfs konvertieren und sich über den gewonnenen Speicherplatz freuen. Das allein wird schon für die meisten als Vorteil reichen.

 

[DoS007]

@Deinorius Nutzt du zstd level 1 oder level 3 und nutzt du Depulikation bei Btrfs? Wie viel Platz kriegst du auf dem SteamDeck von wie viel vorher beanspruchten Speicher frei?

 

[Krik]

Also ich speichere nicht viel auf der internen SSD von meinem Steam Deck. Die Spiele landen alle hauptsächlich auf der SD-Karte.

 

[Deinorius]

@DoS007
Auf meinem Laptop nutze ich zstd:3, den Standard. Auf meinem Steam Deck habe ich noch nicht konvertiert, weil ich genug Platz habe und an sich seit längerem einiges vorhabe, um den Leistungs- und Platzbedarfsunterschied aufzeigen zu können. Steamdeck-btrfs ist aber schon installiert. xD (Das SD läuft gerade so schön.)
Es gibt aber Angaben im Internet, die zeigen, dass dabei einiges frei wird.

 

[andy_m4]

Würde das nur bei einer Distribution verwenden, die das automatisch mitbringt und sich nicht vor den Lizenzrechten fürchtet wie der Linux-Kernel

Solche Probleme umgeht man natürlich sämtlichst bei FreeBSD. Dort ist es direkt im System integriert.

 

[DoS007]

@andy_m4 Leider wird FreeBSD von vielen anderen Dingen nicht so supported (zumindest offiziell). Steam mit Spielen, rustdesk um nur zwei Beispiele zu nennen.

 

[andy_m4]

Leider wird FreeBSD von vielen anderen Dingen nicht so supported

Gut. Das Problem hast Du aber immer, das Du dich im vorhinein informieren musst, ob auf XYZ funktioniert bzw. offiziell supportet ist. Das hast Du auch, wenn Du eine beliebige Linux-Distribution nimmst.

Steam mit Spielen, rustdesk um nur zwei Beispiele zu nennen.

Ohne es jetzt selbst ausprobiert zu haben, aber:

• Steam: https://cgit.freebsd.org/ports/tree/games/linux-steam-utils
• RustDesk: https://cgit.freebsd.org/ports/tree/net/rustdesk-server

 

[DoS007]

@andy_m4 Möchte nicht groß rumfuckeln. Glaube sind uns schon einig, dass Linux out of the box bei dem Großteil besser supported ist (wenn auch nicht so gut wie Windows).

 

[andy_m4]

Glaube sind uns schon einig, dass Linux out of the box bei dem Großteil besser supported ist

Ja. Kann man vermutlich so sagen.
Trotzdem hab ich immer ein Problem mit diesem "supportet mehr"-Argument. Wichtig ist nicht, wie viel supportet wird, sondern das die Sachen funktionieren, die ich brauche.
Und wenn dann obendrein noch Beispiele genannt werden, die schon augenscheinlich nicht passen, dann ists halt erst recht doof.

 

[DoS007]

Ohne es jetzt selbst ausprobiert zu haben, aber

eben. Bei Linux weiß man, dass es funktioniert, weil offiziell supported.

Edit: Ergänzend: Und vllt installiert man auch mal was, was man vorher gar nicht wusste, dass man es haben will. Mehr support in generellen ist also besser.

 

[andy_m4]

Bei Linux weiß man, dass es funktioniert, weil offiziell supported.

Weißt Du im Zweifel eben nicht. Es gibt tausende von Distributionen. Das heißt, auch hier musst Du Dich im Zweifel vorher Informieren.

Und vllt installiert man auch mal was, was man vorher gar nicht wusste, dass man es haben will.

Da musst Du aber bei Linux auch drauf achten. Dann solltest Du eine umfangreiche Mainstream-Distribution nehmen. Da stehen dann die Chancen ganz gut.
Einfach nur blind irgendwas nehmen wo "Linux" drauf steht reicht aber nicht.

Das die Chance unter Linux höher ist, dem würde ich auch gar nicht widersprechen wollen.

 

[DoS007]

@andy_m4 Mit was Ubuntubasiertem fährt man supportmäßig in der Regel ganz gut.

 

[andy_m4]

Mit was Ubuntubasiertem fährt man supportmäßig in der Regel ganz gut.

Ja. Das glaube ich auch, auch wenn ich persönlich ein Debian einem ubuntu vorziehe.

 

[DoS007]

@andy_m4 Auf dem Desktop, warum? apparmor, firewall, snap support, guter ZFS support standardmäßig aktiv, vermutlich neuere Software bei apt. nicht so bei Debian. unbedingt alles frei hat zudem auch Nachteile. nvidia Treiber , multimedia codecs bei Ubuntu besser.