[linux_var] fs compresso

Luca Lesinigo lucky a luckyluke.org
Gio 19 Lug 2007 14:57:13 UTC


Il giorno 04/giu/07, alle ore 18:36, Natalino Picone ha scritto:
> Qualcuno ha info di file system compressi (tipo i vecchi stacker &  
> doublespace) usabili sotto linux ???
Ripesco il thread (perdonate la mia lettura saltuaria delle varie ml)  
per segnalare un paio di cose che non ho visto nelle risposte.

Ci sono diversi casi di fs compressi per usi specifici, quali sistemi  
embedded e/o readonly, che ti sono già stati citati. Ma c'è qualcosa  
anche per i filesystem 'general-purpose' per l'uso quotidiano nei pc.  
Ti hanno già citato Reiser4, che è in beta e non inclusa nel kernel  
stock (a proposito, leggo ora che pare assodato che Hans Reiser non  
sia l'assassino di sua moglie...).

Per cominciare, anni fa esisteva e2compr, che usai con estrema  
soddisfazione su un notebook. Le directory di man, doc e sorci vari  
comprimevano che è una bellezza. E anche i binari x86 di solito si  
comprimono bene (~ 50%). Ovviamente le prestazioni ne risentivano con  
le cpu di allora, parliamo di Pentium133 ad andar bene.
Non è (afaik) mai stato portato su ext3, né la versione ext2 è mai  
stata portata su kernel recenti (è 2.4-only). C'era stato un abbozzo  
di e2compr portato su un 2.6 ma non andava già ai tempi, figuriamoci  
coi kernel recenti. L'abbandonato progetto è su http:// 
e2compr.sourceforge.net/

I motivi per usare la compressione, oltre a hardware limitato,  
possono essere altri. Ad esempio su hardware recente la compressione  
non si nota a livello di cpu (i processori sono molto più potenti di  
un tempo), ma consente di ottenere più velocità dai dischi (!) poiché  
si spostano meno dati tra cpu e piattelli dei dischi (il cui aumento  
di prestazioni non è stato proporzionale a quello delle cpu).  
Ovviamente per notare differenze apprezzabili dovete avere tanti  
dischi e scriverci tanta roba :)

Per quanto attiene i livelli di compressione. Notoriamente gli  
eseguibili comprimono abbastanza bene, come dicevo sopra fino al 50%  
circa della dimensione originale. File testuali e dintorni ovviamente  
si comprimono *molto* (questo vale anche per i log... directory con  
giga di log files diventano qualche centinaio di mega). Materiale  
come foto video e audio non comprime per niente, supponendo che  
stiate già usando un codec che comprime (vedi MPEG (audio e video) e  
JPEG e dintorni).


Attenzione: segue parte non-linuxiana e non-GPL-licensed :-)

Segnalo anche ZFS (quello sviluppato da Sun) che ha la compressione  
builtin. Può usare un algoritmo molto leggero e veloce, di cui  
praticamente non vi accorgete (a livello di uso cpu), oppure gzip,  
che però si sente eccome. Gzip comprime 'un pochino' meglio e usa 'un  
sacco, anzi di più' risorse di calcolo.
ZFS la trovate in OpenSolaris ed in FreeBSD-CURRENT (prossimamente in  
FreeBSD 7.0-RELEASE quando uscirà). Dovrebbe esserci anche qualcosa  
per FUSE sotto linux, ma ovviamente non è 'production-ready', se non  
altro a livello di prestazioni.
Credo che nell'ambito dei filesystem unix 'puri' (lasciamo fuori  
NTFSv1234, per favore :) sia l'unico ad essere "production-ready" *e*  
ad avere la compressione builtin (oltre a tante altre cosette carine).

Nel caso specifico di ZFS un algoritmo si accorge se state mettendo  
su roba non comprimibile e disattiva la compressione in modo  
trasparente (in caso contrario il tutto occuperebbe *più* spazio), ed  
ovviamente riattiva la compressione quando arrivano dati comprimibili.

Per riportare un caso di vita vissuta, sul mio fileserver con ZFS e  
algoritmo LZJB (quello 'leggero') ho un ratio di compressione totale  
di 1.02x, in pratica 102GiB di dati occupano 100GiB su disco - ma c'è  
da dire che è un pastone di molti tipi di dati diversi.

Più interessante segnalare il 1.23x di compressione sul backup del  
webserver. In pratica copio (con rsync su ssh lanciato da cron) il  
contenuto delle DocumentRoot dei siti (file php, html, python, perl,  
oltre ovviamente ad immagini e flash vari) ed i file di log del  
webserver - insomma tutto tranne il db mysql.

Altro caso: una zona solaris (per chi non le conosce, immaginatevi  
una sorta di chroot più evoluto) "sparsa" (ovvero che monta /usr e / 
lib e poco altro in loopback readonly dalla zona globale, mentre ha  
una sua copia locale di tutto il resto) mi fa 1.91x di compressione.  
Si tratta di un po' di eseguibili (/opt) e poi di tutti i file di  
configurazione, log, ed altro (/etc, /var, e via dicendo). Il ratio  
sta pian piano salendo con l'uso, immagino dovuto all'aumentare dei  
file di log che si comprimono molto bene.

Tra l'altro se aggiungiamo l'uso dei cloni (snapshot scrivibili,  
ovviamente sempre compressi), due zone mi occupano su disco 535MiB  
(la seconda zona fatta a partire da un clone della prima), quando in  
realtà si tratta di oltre 1.6GiB di roba se fossero due filesystem  
separati e non compressi. Ogni nuova zona creata come snapshot della  
prima occupa poche decine di mega per rappresentare gli stessi ~  
800MiB di dati.

Avevo fatto test comparativi tra LZJB e GZIP9 (cioè gzip a livello 9,  
il massimo, di compressione). Su dati non comprimibili non cambiava  
ovviamente nulla, su dati comprimibili si guadagnava, ad esser  
fortunati, uno o due punti percentuali di compressione in più, a  
fronte di una notevole e tangibile riduzione delle prestazioni (per  
le prove ho usato un pentium4 1.7GHz, non un i486!). Quindi è inutile  
per un filesystem 'live' spingere molto, è sufficiente un algoritmo  
leggero, ed i dati comprimibili si lasceranno comprimere abbastanza  
bene.

Diciamo che in un ambito puramente 'home media center' si ottengono  
livelli di compressione circa nulli dato che il 99% dei dati saranno  
roba multimediale già compressa dal codec, ma in un ambito 'server'  
con file di configurazione, file di log, documenti web, caselle email  
e via dicendo si ottengono risultati decenti. Si può quasi arrivare a  
recuperare ciò che ci viene rubato dai produttori di dischi, nel  
senso che si riesce circa a mettere 400GiB [400 * 1024^3] di dati su  
un disco da "quattrocento giga" [400 * 1000^3, ovvero 372.5GiB] -  
sarebbe un ratio di compressione 1.07x, anche se non tiene conto  
dell'overhead del filesystem stesso. Spannometricamente.

--
Luca Lesinigo
http://www.SemLUG.net/
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.linuxvar.it/pipermail/talking/attachments/20070719/480cbd42/attachment.html>


More information about the Talking mailing list