Daten-Dateien von C-Programmen mit C-Funktionen Komprimieren/Dekomprimieren?

[nobody0]

Für ein C-Programm unter Linux suche ich noch eine Möglichkeit die persistent gespeicherten Daten zu komprimieren, weil die Dateien sonst zu gross sind und auch das Laden/Speichern auf Festplatte zu lange dauert. Bisher ist mir nur eingefallen die Daten in eine temporär-Datei in eine Ramdisk zu schreiben und sie dort mit gzip zu Komprimieiren/Dekomprimieren und zu Verschieben, aber gibt es denn keine C-Funktionen, mit denen man in einer Datei komprimiert Schreiben/Lesen kann?

Und gibt es auch unter Linux komprimierende Dateisysteme, so dass ich transparentes Komprimieren/Dekomprimieren verwenden kann?

[anda_skoa]

Original geschrieben von nobody0
Für ein C-Programm unter Linux suche ich noch eine Möglichkeit die persistent gespeicherten Daten zu komprimieren, weil die Dateien sonst zu gross sind und auch das Laden/Speichern auf Festplatte zu lange dauert. Bisher ist mir nur eingefallen die Daten in eine temporär-Datei in eine Ramdisk zu schreiben und sie dort mit gzip zu Komprimieiren/Dekomprimieren und zu Verschieben, aber gibt es denn keine C-Funktionen, mit denen man in einer Datei komprimiert Schreiben/Lesen kann?

Natürlich gibt es solche Funktionen in Bibliotheken.
Zum Beispiel in der zlib: http://www.gzip.org/zlib/

Und gibt es auch unter Linux komprimierende Dateisysteme, so dass ich transparentes Komprimieren/Dekomprimieren verwenden kann?

Ja, da gibt es sicher mehrere.
Knoppix verwendet auch sows in der Art.
Es gibt auch patches für ext2 (zumindset fand ich auf http://e2fsprogs.sourceforge.net/ext2.html eine entsprechenden Hinweis)

Nachtrag: http://cvs.bofh.asn.au/e2compr/

Ciao,
_

[Lin728]

Danke anda_skoda!

Ich suche schon lange nach Dateisystemen die transparentes Komprimieren wie unter NTFS unterstützten.
Leider gibt es kein Mainstream Dateisystem wie etx3, xfs, jfs, reiserfs , das transparente komprimierung unterstützt.

Aber für ne Datenpartition sollte sieses ext2compr schon reichen!

Mfg

[anda_skoa]

Möglicherweise ist der patch auch auf ext3 andwendbar.
ext3 ist ja selbst ein ext2 Patch.

Bei der Google Suche hab ich ein paarmal JFS erwähnt gesehen.
Vielleicht hat das auch einen entsprechenden Modus oder er ist geplant.

Ciao,
_

[nobody0]

Aha, dann habe ich ja eine grosse Auswahl und werde der Einfachkeit halber ein komprimierendes Dateisystem nehmen; damit habe ich den geringsten Aufwand. Die Komprimierung ist dann bezüglich Komprimierungsfaktor und Perfomance sicherlich so, als ob ich in eine Ramdisk kopieren würde und von dem Abspeichern auf disc dann mit gzip packe, oder?

[nobody0]

Hm, sieht so aus, als wäre e2compr in den 2.4er Kernel aufgenommen, denn das gibt es nur für 2.0er und 2.2er Kernel, aber genaueres weiss hier wohl auch keiner, oder?

[anda_skoa]

Original geschrieben von nobody0
Aha, dann habe ich ja eine grosse Auswahl und werde der Einfachkeit halber ein komprimierendes Dateisystem nehmen; damit habe ich den geringsten Aufwand. Die Komprimierung ist dann bezüglich Komprimierungsfaktor und Perfomance sicherlich so, als ob ich in eine Ramdisk kopieren würde und von dem Abspeichern auf disc dann mit gzip packe, oder?

eine komprimierendes FS ist wahrscheinlich performanter, aber es könnte vielleicht weniger stark kompriemieren.
Das hängt davon ab, wie es implementiert ist und mit welchem Compressionstool man vergleicht.

Das direkte Benutzen der zlib ist das portablste, weil zlib praktisch fast überall verfügbar ist, RAM disk oder compression FS zeurst eingerichtet werden müssen.

Wenn deine Software nur Betandteil eines System ist, das zusammen installiert wird, dann geht das natürlich.

Bei normaler Software muß man halt abwägen, ob diese Einschränkungen tragbar sind.

Ciao,
_

[nobody0]

Aha. Also weil die Kompresson von dem e2compr bzip ist, nehme ich das; ist auch einfacher auf ein ex2-Verzeichnis

chattr -R +c

anzuwenden als in einem Programm jede I/O-Anweisung mit der zlib zu machen, also umzustellen.

Ich habe das gerade ausprobiert und das funktioniert; anscheinend ist das nun im Kernel (nur mit dem von SuSE 8.0 getestet):

lycee:~ # lsattr /tmp1
-------c------ /tmp1/lost+found
-------c------ /tmp1/q3.out2

Übrigens ist mir noch ein anderer Vorteil vom transparenten Komprimieren eingefallen: auf meinem SMP-Rechner läuft das Programm nur auf einer CPU und das transparente Komprimieren läuft garantiert hautsächlich auf der anderen; die beiden CPUs werden gleichmässiger ausgelastet und die Performance müsste fast doppelt so hoch sein wie mit der zlib

[anda_skoa]

Original geschrieben von nobody0
Aha. Also weil die Kompresson von dem e2compr bzip ist, nehme ich das; ist auch einfacher auf ein ex2-Verzeichnis

chattr -R +c

anzuwenden als in einem Programm jede I/O-Anweisung mit der zlib zu machen, also umzustellen.

Tolle Sache, wußte nicht, dass das so einfach geht!

Ciao,
_

[nobody0]

Hm, irgendwie funktioniert das nicht: ich kann zwar das Attribut setzen, aber wie ich mit df sehe, wird nix komprimiert (wegen der Transparenz zeigt ls keine Kompression); eine Datei, die mit
dd if=/dev/zero of=zero1.tmp bs=512 count=1000000
erstellt wird, belegt auch mit Komprimierung rund 500 MB, obwohl die durch Komprimierung auf 1/1000 reduziert werden sollte

Aber nach man chattr sollte das funktionieren:

"
A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk.
"

[nobody0]

Jetzt weiss ich durch google mehr:

- Das chattr -c wird von ungepatcheten Kerneln ignoriert :
http://online.securityfocus.com/infocus/1407

- Neuester Kernel-Patch ist nur für 2.2er Kernel:
http://www.ripnet-uk.com/RipNet_v2/l...x_kernel.shtml

Damit ist das unbrauchbar für mich

[Lin728]

Wirklich schade!

Da finde ich das, was ich schon immer für Linux gesucht habe, und dann läuft es nur auf 2.2er Kernel
Mfg

[nobody0]

Original geschrieben von ceisserer
Wirklich schade!

Da finde ich das, was ich schon immer für Linux gesucht habe, und dann läuft es nur auf 2.2er Kernel *wein*

Mfg Clemens

Tja, man kann ja man an die Kernel-Entwicker appelieren das in den Standard-Kernel aufzunehmen, denn das Datenschutzargument dagegen ist sinnlos, weil das e2compr anscheinend stabil ist und Sachen wie Schreibcache-Aktivierung (mittels hdparm) schliesslich auch zur Datenbeschädigung führen können.
Man könnte ja mal eine Umfrage starten, denn wenn man viele unkomprimierte Daten hat, dann ist das sinnvoll; insbesondere, wenn man von seiner CD-Sammlung ein Backup auf einer Festplatte anlegt (bei mir sind das um 50 GB, die auf ca. die Hälfte reduziert werden könnten).