Re: on-the-fly file compression
On Sat, Jul 29, 2006 at 01:28:51PM +0200, Richard Mittendorfer wrote:
> Also sprach Peter Wiersig <peter@friesenpeter.de>
> > On Sat, Jul 29, 2006 at 12:44:36PM +0200, Richard Mittendorfer wrote:
>
> > > Reiserfs V4 kann das, aber laeuft das schon stabil? Gibt's
> > > e2comp Patches fuer >2.6.1x? Mit FUSE, einem loop-Device oder
> > > mit einer Device Mapper Erweiterung vielleicht?
> >
> > FUSE oder DM am ehesten. Reiser4 ist sicher auch eine Option. Ich
> > denke das reiser4 schon in den Testbetrieb gehen kann.
>
> Kennst du fuer erstere eine Variante?
FUSE kenne ich aus der Beschreibung. Damit kann ich mir
vorstellen, das man ein ZIP-File als Dateisystem einbindet, damit
im Mountpoint ein Verzeichnis erhaelt welches die Daten des ZIPs
abbildet. Jedes Kommandozeilentool koennte dann mit den Dateien
wie bei jedem anderen Dateisystem auch arbeiten.
Die Kernel-Zugriffsoptimierungen wie "sendfile" wuerden aber unter
den Tisch fallen. Ich kann mir nicht vorstellen, das die
FUSE-Schicht mehr als read und write unterstuetzt.
> Rasierfs4 war meine erste Ueberlegeung. Nachdem es aber den
> (typischen) Streit um die Integrierung nach stable gibt, bin ich
> mir nicht ganz sicher.
Nein, den "typischen" Streit gibt es Dank der Querelen um
reiser3, welches nach Aussagen von Hans Reiser nicht mehr weiter
gepflegt werden soll.
Als Episode sei da die Veraenderung der Kernel-Stackgroesse auf
4kb genannt. Selbst heute noch schreibt die reiser4 die (veralte,
hoffe ich) Anweisung in der reiser4 Installationsanleitung das man
an dieser Kerneleinstellung keinesfalls rumstellen darf.
> Ausprobieren waer' da sicherlich die beste Moeglichkeit den
> Stand 'rauszufinden.. ;-)
Das waere durchaus gewuenscht. Ich plane das auch bei den
naechsten Kerneluebersetzungen mit hineinzunehmen.
> > > Komprimierungsrate will ich so etwa 2:1,
> >
> > fuer welche Rohdaten? Text? Binaere Word-Processor Dateien?
> > Kompremierte Dateiformate?
>
> Grossteils Doks (html, pdf, ps, doc, ..), einige Images und
> mysql-db's und ein Haufen ogg vorbis. Insgesammt etwa
> 50+20+10+20GB.
Die erste Gruppe (Doks) bitte noch einmal genauer aufschluesseln.
html und ps lassen sich noch gut verkleinern, bei pdf und doc
bzw. odf sind die Dateien teilweise schon kompremiert. Wie bei ogg
und jpg werden die dann eher groesser als kleiner.
> Wichtig dabei ist mir, dass die Kompression ein File als stream
> verabeiten koennen muss -- einige scheinen es im virtuellen
> Speicher zu komprimieren -- davon hab' ich nicht genug.
Noch einmal genauer bitte: Du moechtest das die Daten, die dein
Programm schreibt moeglichst schnell kompremiert haben, also auch
schon bevor sie zur Platte geschreiben werden. Umgekehrt sollen
sie erst dann dekompremiert werden, wenn aus der Datei gelesen
wird, d.h. den Kernel-Buffer am liebsten kompremiert?
Das klingt dann nach einem groesseren Eingriff. Keine der mir
bekannten Loesungen waere da direkt einsetzbar.
Andernfalls erklaere nochmal, was du mit virtuellem Speicher
meinst. Und wie deine Nutzung aussehen soll, wenn du vom File als
stream sprichst.
Peter
Reply to: