Re: on-the-fly file compression
Also sprach Peter Wiersig <peter@friesenpeter.de> (Sat, 29 Jul 2006 14:00:57 +0200):
> 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.
Werd' ich mir genauer ansehen. fuse.txt sagt mir einstweilen nicht
viel, aber da sollte Info im Netz zu finden sein. Ich dachte
urspruenglich, dass ein loop-dev die leichteste Variante waer'?
> > 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.
See.
> 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.
Oh, danke fuer den Hinweis. Seit Monaten fahre ich 4k stacks.
> > Ausprobieren waer' da sicherlich die beste Moeglichkeit den
> > Stand 'rauszufinden.. ;-)
>
> Das waere durchaus gewuenscht. Ich plane das auch bei den
> naechsten Kerneluebersetzungen mit hineinzunehmen.
Ich werd' mal ins kalte Wasser springen. Schnell soll es ja sein.
> > > > 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.
Fast alles html. Klar, fuer Komprimiertes wird's weniger hilfreich.
> > 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.
Dass ein z.B. 700MB grosses file nicht erstmal im RAM+SWAP komprimiert
wird und dann auf's FS gelegt wird. Einige Komprimierungsverfahren
gehen so vor, IIRC weil ja ein seek in einer (z.B. gzip-)Datei nicht
gut moeglich ist. Zumindest bei der einen oder anderen
Kompressionsmethode duerfte das greifen. Wohl aber nicht bei reiserfs
v4 (das wohl meine Wahl sein wird).
> Peter
sl ritch
Reply to: