Re: on-the-fly file compression
Argh, verschicke keine Mails, wenn du gerade den Mailrouter
aktuallisierst. rewritten & resend. ;-)
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.
fuse.txt sagt mir im Moment noch nicht viel. Dazu lassen sich aber
sicher Infosa im Netz auftreiben. Urspruenglich ging' ich eigentlich
davon aus, dass ein loop-dev die einfachste Variante sein wuerde?
> > 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.
I 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. Ich fahre seit Monaten 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 spring mal ins kalte Wasser und seh' mir reiserfs4 an. Schnell
soll's ja ueberdies sein -- Hoffentlich nicht "schnell kaputt". :-)
Andere FS-Loesungen sind scheinbar keine vorhanden. e2comp vielleicht,
aber da finde ich nichts aktuelles.
> > > > 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 ausnahmslos html. Bei komprimierten files wird's klarerweise nicht
viel bringen.
> > 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.
Ein z.B. 500M File soll nicht erst im VM (RAM+SWAP) komprimiert werden
und dann auf die Platte geschrieben werden (also eigentlich umgekehrt:
lesen + dekomprimieren -> VM -> bearbeiten), wie es einige Loesungen
scheinbar machen, IIRC weil ja ein seek in einer (LZW-)komprimierten
Datei schlecht moeglich ist. D.h. das soll/muss der Treiber des FS
handlen koennen.
> Peter
sl ritch
Reply to: