Komprimierte Verzeichnisse mittels ZFS auf ext4

[porthos]

Komprimierte Verzeichnisse mittels ZFS auf ext4

Ich suche ein HOWTO (CLI, nicht GUI-Zeugs) fürs Einrichten von Compressed Directories
mittels "zfs-fuse" auf dem Standard ext4-Dateisystem unter Linux (VPS, aber auch für zu hause auf Workstation).

Das ZFS-Dateisystem scheint "transparent directory compression" anzubieten.
Aber erschwerend kommt hinzu dass es 2 ZFS unter Linux gibt: ein normales und dann ein zfs-fuse.
Ich will das Standard-Dateisystem ext4 beibehalten und nur da drauf eine virtuelle
ZFS-Partition (d.h. eine grosse Partitions-Datei) anlegen, mounten usw., also muss ich wohl zfs-fuse nehmen.

Der Sinn und Zweck des ganzen ist um ausgewählte Verzeichnisse autom. transparent komprimiert zu halten (sehr viele html, csv, json, txt und source-Dateien), wie das doch schon seit mehr als 25 Jahren oder so unter Windows möglich ist (oder war; lang ist es her bei mir mit Windows NT und XP ).

Ehrlich gesagt, finde ich es als ein Armutszeugnis dass Linux komprimierte Verzeichnisse nicht standardmässig hat. Oder habe ich da vlt. was übersehen?

Hat jemand Erfahrung mit diesem Thema (Compressed Directores unter Linux auf ext4) und könnte helfen?

Thx

 

[greystone]

ZFS macht das halt einfach anders. ZFS komprimiert Volumes und nicht Verzeichnisse und Dateien. Du kannst natürlich so viele Subvolumes anlegen wie Du willst und diese Subvolumes stellen dann effektiv einzelne Verzeichnisse dar, worauf die Subvolumes eingehängt sind. Für jedes einzelne Volume oder Subvolume kannst Du dann gezielt die Kompression einstellen. Ansonsten ist es auch durchaus zu empfehlen, die Kompression global einzuschalten - es sei denn, das CPU-Performance auf dem System eine sehr knappe Resource ist. Das bringt in vielen Fällen zusätzliche Performance, weil die IO-Bandbreite - auf Kosten von etwas CPU-Leistung - erhöht wird. D. h. es müssen bei gleicher Datenmenge weniger Daten vom/zum Datenträger gelesen/geschrieben werden, was insgesamt die verfügbare IO-Bandbreite besser ausnutzt. Das ganze funktioniert auch gut mit Daten die sehr schlecht komprimierbar sind. Technisch funktioniert das so, dass der Kompressionsalgorithmus erst prüft, ob die Daten gut komprimiert werden können. Ist das nicht der Fall, werden die Daten unkomprimiert geschrieben, um nicht unnötigerweise CPU-Resourcen zu verschwenden.

Wenn Du gezielt Verzeichnisse und Dateien komprimieren möchtest, dann nutze btrfs. Das geht das genau so, dass man auf der Ebene von Verzeichnissen und Dateien die Kompression steuert. btrfs macht aber ein paar Dinge sehr anders und deswegen sollte man sich da gut einlesen. ZFS macht Dinge von sich aus Dinge so, dass nichts kaputt geht. Manches kann man dort gar nicht steuern. btrfs kannst Du ganz gezielt nach Deinen Wünschen verwalten. Wenn Du es aber nicht richtig machst oder wichtige Schritte vergisst, dann hat das möglicherweise drastische Konsequenzen. Da btrfs direkt im Kernelcode entwickelt wird, ist die Empfehlung dafür möglichst aktuelle Kernel zu verwenden.

Von ZFS-fuse würde ich die Finger lassen. Soweit ich das sehe findet die Entwicklung von ZFS in OpenZFS statt. Müsste jetzt erst mal googeln, ob ZFS-fuse überhaupt noch aktuell ist und was da der Status ist.

Ich will das Standard-Dateisystem ext4 beibehalten und nur da drauf eine virtuelle ZFS-Partition (d.h. eine grosse Partitions-Datei) anlegen, mounten usw., also muss ich wohl zfs-fuse nehmen.

Ja. Das würde ich jetzt mit einem normalen ZFS auf keinen Fall so tun. Das könnte man zwar. Aber ich vermute, dass ist nicht performant und sauber. Aber wenn Du ZFS-fuse verwendest, dann dürfte die Performance ohnehin deutlich schlechter sein.

Die Empfehlung ist grundsätzlich die ganze Platte unter ZFS-Verwaltung zu stellen.

Welche Gründe hast Du dafür, dass so betreiben zu wollen?

 

[porthos]

@greystone, danke für die Info. Über btrfs muss ich mich noch schlau machen,
aber ich will ja ext4 beibehalten. Ich befürchte virtuelles btrfs auf ext4 geht wohl nicht.
zfs-fuse ist im aktuellen Debian-repo.

 

[porthos]

Welche Gründe hast Du dafür, dass so betreiben zu wollen?

Ich will bei so wichtigen Sachen wie dem Dateisystem bei Default-Standards bleiben, also ext4.
(Denn überlege mal wie ich es auf einer remote VPS einzurichten hätte wenn ich nicht bei Standards bleiben würde...).

Und: Performance ist in diesem Fall nicht so wichtig weil Zugriff auf diese Dateien ist selten; da ist fuse-Performance
völlig ausreichend. Es geht vielmehr um Disk-Space einzusparen, ohne Archive zu benutzen...

 

[greystone]

Ja. Ich verstehe, warum Du das so machen möchtest. Ich würde das aber nicht sagen, dass es hier um den "Default-Standard" geht sondern um die Flexibilität, das unabhängig vom System überall gleich machen zu können und Du möchtest eine Möglichkeit für eine transparente Kompression, bei dem Du bzgl. der Anwendung nichts implementieren möchtest. (Vor Zugriff temporär dekomprimieren, ...)

Bei solchen Loop-Dateisystemgeschichten könnte ich mir nur vorstellen, dass das Dateisystem bei Abstürzen leichter beschädigt werden könnte, weil da dann auf zwei Ebenen Dateisystemcaches da sind. Eine Absicherungsmöglichkeit wäre es hier, das ZFS im Normalfall nur Read-Only eingehängt zu haben und bei Bedarf mal zu Read-Write zu ändern und nach dem Schreibvorgang dann gleich wieder zurück.

Der Vorteil von FUSE gegenüber einem nativen Kerneltreiber ist die Unabhängigkeit eben von einer neuen Kernelversion. Insofern auch wieder der Punkt für größerer Flexibilität.

Mit btrfs dürfte das genauso gehen. Allerdings sind - wie schon geschrieben - bei btrfs aktuelle Kernel zu empfehlen.