Newsgroup: it.comp.os.linux.sys
Titolo: Bacula e compressione HW...

 
Googolando mi pare di non essere l'unico ad avere codesto dubbio, ma la
risposta è sempre ''avrai materiale che non si comprime''.
 
Fatto sta che anche io ho:
 
 *list media pool=ThorLTOPool
 +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
 | MediaId | VolumeName | VolStatus | Enabled | VolBytes        | VolFiles | VolRetention | Recycle | Slot | InChanger | MediaType | LastWritten         |
 +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
 |      36 | Thor001    | Append    |       1 | 821,781,622,784 |       78 |    2,419,200 |       1 |    0 |         0 | LTO-4     | 2017-02-05 23:36:06 |
 |      38 | Thor002    | Used      |       1 | 864,515,769,344 |       82 |    2,419,200 |       1 |    0 |         0 | LTO-4     | 2017-01-12 23:53:24 |
 |      39 | Thor003    | Full      |       1 | 948,821,193,728 |       92 |    2,419,200 |       1 |    0 |         0 | LTO-4     | 2017-01-18 23:53:59 |
 |      40 | Thor004    | Used      |       1 | 920,876,047,360 |       88 |    2,419,200 |       1 |    0 |         0 | LTO-4     | 2017-01-27 00:04:04 |
 |      41 | Thor005    | Full      |       1 | 947,125,326,848 |       91 |    2,419,200 |       1 |    0 |         0 | LTO-4     | 2017-02-01 23:58:25 |
 +---------+------------+-----------+---------+-----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
 
950 giga per un media che ne dovrebbe tenere 800/1.600 mi pare un po'
pochino. Considerando che li dentro ci sono le home (posta, in primis).
 
 
Quasi quasi provo ad abilitare la compressione software, ma mi scoccia...
 
-- 
  ``... La memoria conta veramente solo se tiene insieme l'impronta del
  presente e il progetto del futuro, se permette di fare senza dimenticare
  quel che si voleva fare, di diventare senza smettere di essere,
  di essere senza smettere di diventare...''		(Italo Calvino)

 Quasi quasi provo ad abilitare la compressione software, ma mi scoccia...
 
Io uso sempre solo tar e cpio per salvare un po di tutto, ma una
compressione 2:1 sui nastri non l'ho mai vista da nessuna parte.
 
Al massimo 1,2:1 che è, guarda caso, 950 Gb su un LTO-4.
 
Sto facendo delle prove con la compressione software che è decisamente
più efficente ma anche molto più lenta :-(
 
 
-- 
Stefano L.

 più efficente ma anche molto più lenta :-(
 
Direi praticamente inutilizzabile per la precisione, almeno per me.
 
Queste sono le prove che ho fatto su un Ultrium LTO-6
 
$ VOL=/voltest
$ du -hs $VOL
18G     /voltest
 
$ time ( tar cf - $VOL | dd of=/dev/st0 bs=240b )
real    5m24.807s
user    0m1.424s
sys     0m41.320s
 
$ time ( tar cf - $VOL | gzip -1 | dd of=/dev/st0 bs=240b )
real    21m7.943s
user    19m7.156s
sys     1m16.584s
 
 
Considerando che ho fatto le prove con una directory da 18 Gb
ma in realta' adesso salvo circa 1.600 Gb in 11 ore, se attivassi
la compressione software impiegherei piu' di 40 ore per i backup
notturni, che sono un po' troppe... 
 
-- 
Stefano L.


Con tar -czf (o j, o J) invece di mettere in pipe gzip come si comporta?
Potresti provare con un algoritmo piu' veloce (che comprime un po' meno) ad esempio lz4.
 
Ciao Jack


https://binfalse.de/2011/04/04/comparison-of-compression/
 
 
Ciao Jack

 Con tar -czf (o j, o J) invece di mettere in pipe gzip come si comporta?
 
In effetti mettere in pipe è un po' una merda, tar gestisce di suo i
compressori, sia con gli appositi switch (z j o J), sia esplicitandoglieli via
con -I (ovviamente il tutto è spiegato nella man page)
 
Enrico

 $ time ( tar cf - $VOL | dd of=/dev/st0 bs=240b )
 
Gentilmente potresti spiegarmi l'uso di quel piccolo block size?
-- 
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 


Ho fatto anche quelle prove.
Se non ho sbagliato nulla è anche peggio !
 
Comunque ricontrollero'
 
-- 
Stefano L.

 Gentilmente potresti spiegarmi l'uso di quel piccolo block size?
 
240x512=122.880 byte
 
Dici che è poco ?
 
Onestamente su quello non ho fatto grandi prove, e' un valore che avevo 
trovato ottimale anni fa in base a delle prove con il solo tar
 ( tar cbf 240 /dev/st0 ..... )
e non mi sono più preoccupato di ricontrollarlo.
 
In ogni caso è lo stesso sia con lo zip che senza.
 
 
-- 
Stefano L.

 
https://binfalse.de/2011/04/04/comparison-of-compression/
 
 
Se non sbaglio a interpretare i dati l'unico in grado di fare meglio
di gzip è il "famosissimo" lzop.
 
Lo proverò.
 
Mi lasciano perplesso due cose, la prima e' il dubbi della sua
affidabilita', non l'ho mai sentito nominare e non vorrei incappare
in qualche bug.
Da questo punto di vista gzip mi lascia molto più tranquillo.
 
Qualcuno usa lzop e puo' dirmi qualcosa in proposito ?
 
La seconda e' che, comunque, nella compressione di dati eterogenei
sembra più veloce di gzip ma comunque poco più del cinquanta percento.
 
Ancora troppo lento per me.
 
-- 
Stefano L.

 Quasi quasi provo ad abilitare la compressione software, ma mi scoccia...
 
Ho notato che, se guardi il link che ha postato Jack
 
https://binfalse.de/2011/04/04/comparison-of-compression/
 
 
noterai che, nella compressione di dati eterogenei, il valore
medio della compressione ottenuto dai vari software è esattamente
uguale a quello ottenuto dalla compressione hardware.
 
Sara' un caso ? 
 
 
-- 
Stefano L.

 Comunque ricontrollero'
 
Tra l'altro, hai provato con pigz al posto di gzip? 


In effetti no, avevo dato per scontato che fosse adatto solo alla 
compressione parallela di file diversi e non all'uso in pipe.
 
Ma googolando vedo che pare vada bene anche in pipe.
 
Oggi provo.
 
-- 
Stefano L.

 Ma googolando vedo che pare vada bene anche in pipe.
 
Seriamente, cos'ha tar -I 'pigz -1' -cvf file.tar.gz * che non ti piace?
 
Enrico

Sara' un caso ? 
 
Tenderei a pensare di no, ma è strano lo stesso.
 
Se l'algoritmo è quello, farlo in software o in hardware non cambia nulla,
e quindi la compressione che m'aspetto sarebbe la stessa... se anche tutti
i parametri dell'algoritmo fossero gli stessi.
 
Ma in software in genere c'ho una CPU e una RAM *assai* superiori a quello
che si può permettere lo hardware, sicché mi aspetterei valori superiori -
nel senso, l'hardware fa gzip -2, il software arriva a gzip -9.
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 Seriamente, cos'ha tar -I 'pigz -1' -cvf file.tar.gz * che non ti piace?
 
Seriamente, nulla.
 
E' piu' una questione estetica e di gusti personali.
 
Tanto alla fine è esattamente la stessa cosa, come si puo' dedurre sia dalla 
man page di tar:
 
     -I, --use-compress-program PROG
           filter through PROG (must accept -d)
 
sia guardando l'output di   'ps -Hef'
 
sia guardando l'output di  'lsof'
 
sia confrontando i tempi totali di elaborazione nei due modi che risultano 
essere praticamente identici.
 
 
-- 
Stefano L.

 Oggi provo.
 
Ho fatto un paio di prove veloci...
 
A entrambi ho passato l'argomento -1
 
In effetti pigz è piu' veloce di gzip.
 
Ma non in modo significativo !
 
Ho avuto poco tempo e ho fatto solo due prove:
 
Se gli do in pasto un volume contenente praticamente solo .jpg allora pigz è 
molto più veloce ma comprensibilmente la compressione è praticamente nulla 
sia per gzip che per pigz.
 
Se, invece, gli do in pasto un volume contenente delle maildir allora
la compressione mi riduce per entrambi la dimensione al 50% dell'originale 
ma il tempo di compressione di pigz è solo il 30% inferiore a gzip.
 
 
-- 
Stefano L.

 più efficente ma anche molto più lenta :-(
 
Letto tutto il thread. Grazie a tutti. ;)
 
-- 
  Se si insegna a un bambino a programmare in qualche linguaggio
  informatico, questo esercizio logico lo renderà padrone e non
  schiavo del computer.					(Umberto Eco)

 ma il tempo di compressione di pigz è solo il 30% inferiore a gzip.
 
Oddio, il 30% di meno non mi sembra poca cosa...
Poi dipende, per la maildir di quanti file stiamo parlando? Su che dischi? Su
che file system?
 
Enrico

 compressori,
 
  No!
 
[alessandro@wkstn05 ~]$ PS -C tar -C xz ; (lsof -p $(pgrep tar) ; lsof -p
$(pgrep xz)) | grep -E 'FIFO|pipe'
USER       PID  PPID %CPU %MEM   RSS TT       STAT  NI  STARTED CMD
alessandro  17957 14240  1.3  0.0  3236 pts/2 S+     0 13:14:20 tar
-cJf /tmp/etc.tar.xz /etc
alessandro  17958 17957 82.6  1.5 60992 pts/2 R+     0 13:14:20 xz
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
tar        17957 alessandro  4w  FIFO 0,9      0t0 129248 pipe
xz      17958    alessandro  0r  FIFO 0,9      0t0 129248 pipe
[alessandro@wkstn05 ~]$ 
 
  Anche tar usa la pipe, nota che la FIFO di tar ha lo stesso inode di quella
di xz.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
VOIP SIP: 
dhata...@ekiga.net
 
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9