Newsgroup: it.comp.os.linux.sys
Titolo: backup directory con ~ 1 milione di file.

Dovrei fare un backup di una directory contenente un milione, o milioni
di file. Il backup dovrà essere da una partizione a un'altra della
stessa macchina (chicca: lanciato in parallelo su una quindicina di
macchine con keyboardcast ;-) )
In passato abbiamo già usato 'tar'. Funziona, ma il backup richiede
fino a due giorni... o forse di più.
Settimana scorsa ho usato dump/restore. Velocissimo. Il backup termina
in due ore ma mi ha sputtanato una miriade di file: all'interno di
alcuni file di testo ho trovato caratteri non ascii. Forse bisogna
giocare con il blocksize, ma non mi pare il caso di andare avanti su
questa strada.
Mi interesserebbe poter fare il backup in tempi rapidi, e... in modo
sicuro. 
Le alternative possono essere:
- rsync (usato localmente)
- pax
- star (ho difficoltà a trovare il binario per la redhat 4 EL).
- dd in pipe con gzip
- il buon vecchio 'cp'
- partimage è buggato, in quando non vede i volumi LVM (se non
  ricordo male vede solo il primo).
- che altro? 
con quali tra questi tool, compreso il "che altro?", potrei ottenere
risultati migliori?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 - che altro? 
mi ero dimenticato 'cpio'. Come ho potuto :)


 
Novità:
'rsync': non posso usarlo perché devo comprimere l'archivio: la
directory di destinazione non ha spazio a sufficienza.
'cp': idem come sopra
'star': buon nuove. Ho trovato il pacchetto x86_64 and maybe can be
the winner.
alcuni test su cpio e pax non danno risultati brillanti per quanto
riguarda le prestazioni (anche se qui parliamo di piccoli file.
'star' e garantito essere - da parte di diverse persone che lo hanno
testato - uno dei più veloci. Ma, visto quello che mi è successo
con dump, mi dovrò fidare di star, oppure mi metto l'anima in pace e
aspettare un paio di giorni che il backup finisca?


 di file.
La cosa e` rognosa a prescindere, una directory con milioni di file e`
sostanzialmente una directory ingestibile. Personalmente andrei di rsync
su di un'altra locazione o, ancora meglio, su di un altro pc e poi con
tar comprimerei il tutto
Enrico

 ha scritto:

in questo momento sto rsyncando un nodo con l'altro (per recuperare il
disastro fatto da dump) :-) Ma quanto dovrò fare il backup di tutta la
piattaforma la situazione sarà ben diversa.
Ti spiego l'architettura e il problema un po' in dettaglio:
- purtroppo si tratta di una database in cluster applicativo, che in
  teoria è compattabile, ma la cui compattazione, nei casi di alcune
  tabelle, può richiedere fino a una settimana: i frammenti sono
  singoli file sul filesystem.
- si tratta di 15 nodi pressoché identici (non cloni: la mole di dati
  è uguale ma i dati sono divisi tra i nodi per un load balancing), con
  un partizione / (root) e una partizione /data.
- Ognuno di questi nodi contiene un milioncino di file.
- devo fare un backup della /data e nella partizione root ho una 40ina
  di giga e, comprimendo, riesco a farci entrare il backup.
- Devo lanciare 15 backup contemporaneamente: mandare in rete 15 backup
  di questo tipo temo che potrebbe creare problemi a switch vari... e
  comunque le prestazioni sarebbero disastrose.
Non so che pesci prendere... in particolare dopo il disastro fatto da
dump.



Personalmente quando devo fare backup di strutture cos� complesse preferisco 
fare la copia del block device sottostante.
Se poi si tratta di un device LVM (cosa auspicabile) sfrutto la funziona 
snapshot e faccio una copia dello snap. Il vantaggio � che non interessa la 
struttura di filesystem soprastante che, quando si ha a che fare con milioni 
di files, comporta rallentamenti enormi ed un uso smodato di risorse; lo 
svantaggio � che ovviamente si copia anche quel che non serve, ovvero lo 
spazio vuoto, e che non � possibile fare salvataggi incrementali.
Se si usa LVM in modo intelligente e si � allocato uno spazio congruo con le 
esigenze di storage, in genere non si supera il 10%-20% di spazio libero nel 
volume, quindi lo spreco � ridotto ed ampiamente compensato dalla semplicit� 
di implementazione e dall'incremento di troughput che si ha bypassando le 
strutture logiche del FS.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 con le esigenze di storage, 
NIET. LVM è stato usato in modo stupido, configurato non so quando, da
non so chi...


 purtroppo non dispongo di altri 30 per poter eseguire lo snapshot.
Ma e come pensavano di fare il backup di tutti questi dati?
Solo un'idea, ma provare ad usare cat sul device della partizione in
tubo con gzip|7zip|bzip2?
Il compressore va ben scelto per ben comprimere, ma anche per essere
veloce e forse non
ammazzare la macchina.
Andrea

Una curiosita`, ma che filesystem e` usato?

 ammazzare la macchina.
Il che rimuove, di fatto, il bzip dai possibili candidati.
Mai visto un compressore lento come lui, comprime come un maiale
ma � di una lentezza stratosferica.

 - star (ho difficoltà a trovare il binario per la redhat 4 EL).
Io ho 2 anni di backup fatti con star (per colpa del limite a 99 caratteri 
di tar) e anche io ho difficolta` a trovare il binario (per Debian, 
qualsiasi versione), quindi stamattina ho provato bsdtar, che supporta 
anche il formato ustar che ho usato nei miei backup.
Prova a vedere se ti puo` essere utile.
Bye.

 ma � di una lentezza stratosferica.
Prova pbzip2 se hai una macchina recente :-)


 Una curiosita`, ma che filesystem e` usato?
ext3 (penso sia quello predefinito della redhat 4 EL)


sono riuscito a trovare start x86_64 rpm ;-)

 ammazzare la macchina.
bzip è lento e gzip è veloce... ma 7zip su linux come gira?

 Prova pbzip2 se hai una macchina recente :-)
Recente per quale motivo? E' un mattone stratosferico o
utilizza qualche accelerazione hardware particolare?

Peregrino 'Pipino' Tuc wrote:

http://compression.ca/pbzip2/

 bzip � lento e gzip � veloce... ma 7zip su linux come gira?
Hai provato xz? Non so com'� veloce ma ho letto che hanno diminuito lo 
spazio dei repositiry della slack di un buon 30%
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Fashion is a form of ugliness so intolerable that we have to alter it
every six months.
		-- Oscar Wilde



ARGH.


Beh, fosse stato BTRFS sarebbe stato peggio, almeno adesso; fra pochi
mesi o anni potra` essere la scelta migliore.

 
http://compression.ca/pbzip2/
Interessante...

 spazio dei repositiry della slack di un buon 30%
Tu non hai mai fatto alcun confronto sulle compressioni, vero?

 qualsiasi versione), 
Uh?
enrico@whiterabbit:~$ uname -a
Linux whiterabbit 2.6.30-1-amd64 #1 SMP Sat Aug 15 18:09:19 UTC 2009 x86_64 GNU/Linux
enrico@whiterabbit:~$ apt-cache search ^star$
star - A fast POSIX-compliant tape archiver
enrico@whiterabbit:~$ cat /etc/apt/sources.list
deb 
http://ftp.it.debian.org/debian/
 unstable main contrib non-free
[...]
enrico@whiterabbit:~$
Enrico

 bzip è lento e gzip è veloce... ma 7zip su linux come gira?
Piu` lento (by design) di Bzip2. Forse Zip e` piu` veloce di Gzip
Enrico

 mesi o anni potra` essere la scelta migliore.
Posto che e` impossibile installare Btrfs su di una RHEL 4 (a meno di
pesanti modifiche che non farei mai in produzione), penso che l'argh sia
dovuto al fatto che gestire cosi` tanti file in una directory con ext3
sia un mezzo suicidio :)
Enrico

 di eventuale snapshot) e un restore di 15 macchine insieme.
Detta cosi` sembra che stai facendo il backup dei datafile di un RDBMS.
Sei sicuro che 'sto coso non abbia un sistema interno per estrarre i
dati in modo portabile (e.g. pgdump, mysqldump, svndump...)?
Enrico

 utilizza qualche accelerazione hardware particolare?
Sfrutta il multicore. La cosa e` interessante, peccato pero` che sia
praticamente un fork e che non sia gestito con gli alternatives in Debian
Enrico

 sia un mezzo suicidio :)
s/sia un mezzo/� un/


 svndump...)?
Ha un suo comando interno backuptbl/restoretbl. A parte il fatto che
potrebbe essere più veloce o più lento (questo non lo so) c'è un altro
problema ancora che ti vado a spiegare: questo DB sta in parte sui
dischi dei 15 server linux, ma passati XX giorni, viene trasferito su
uno storage esterno (si tratta di uno storage esterno specializzato
nella archiviazione dei dati di audit, che consente l'archiviazione ma
non la cancellazione).
Cosa vuol dire questo?
vuol dire che sei io faccio il backup della intera tabella, farei il
backup anche di ciò che sta sullo storage esterno (che fra l'altro è
lento da morire). Il che vuole dire fino a due anni di dati, contro i
15 giorni di dati che stanno sui dischi.
Infine, sui dischi mi ritrovo file che spesso sono antecedenti gli XX
giorni (file di cache delle query o file che arrivano con timestamp
errati), quindi (ammesso che si possa fare) non posso fare nemmeno un
backup parziali delle tabelle da quel timestamp a quell'altro
timestamp. Sul disco a volte vedo directory con namespace 1970: si
tratta di caricamenti freschi, la cui sorgente produce i dati con un
timestamp non corretto che viene scartato dal server.
Al posto del timestamp viene inserito 1970.



No, ho letto che (ecc ecc)



Mi correggo, l'ho fatti adesso (un tar di un kernel linux con parametro -9) 
e xz comprime di più, c'è poco da fare.
I tempi però sono biblici
422707200 2009-09-16 08:00 test.tar
97513398 2009-09-16 08:27 test.tbz2
117272173 2009-09-16 08:25 test.tgz
59474200 2009-09-16 08:36 test.txz


 
http://ftp.it.debian.org/debian/
 unstable main contrib non-free
Ammetto che in unstable non ho cercato, ma avevo i repository di lenny e 
squeeze configurati e non me lo trovava... :/
E nemmeno su getdeb e backports.
Meglio. Mi faro` un backport a mano, allora. :)
Bye.

 No, ho letto che (ecc ecc)
Ecco, io ho letto ed ho fatto le prove ottenendo gli stessi risultati.
E cioe' che comprimere molto e' una follia anche con le cpu odierne.
http://planet.debian.net/cgi-bin/search.cgi?terms=jgoerzen
In pratica: usa gzip. O lzop che comprime ancor meno ma e' praticamente 
gratis. Altrimenti sono dolori.
Un esempio, il pacchetto di ghostscript:
gs.tar       65003520 bytes  (original file)
gs.tar.lzma  12751330 bytes  (159.05s to compress, 1.48s to decompress)
gs.tar.xz    12768488 bytes  (155.17s to compress, 1.54s to decompress)
gs.tar.lz    12804165 bytes  (161.12s to compress, 1.97s to decompress)
gs.tar.bz2   16921504 bytes  ( 14.72s to compress, 3.45s to decompress)
gs.tar.gz    19336239 bytes  (  7.31s to compress, 0.63s to decompress)
gs.tar.Z     29467629 bytes  (  2.39s to compress, 0.78s to decompress)

 
Pardon. Ecco la tabella di ghostscript


 E cioe' che comprimere molto e' una follia anche con le cpu odierne.
Direi che è la scoperta dell'acqua calda. E comunque tutto dipende dagli 
obiettivi che devi raggiungere; passare da 19MB a 17MB o a 13MB può essere 
molto più importante del tempo che ci metti a raggiungere l'obiettivo.
Senza contare che l'uso di compressori paralleli (ancora pochi per la 
verità) e la disponibilità ormai costante di macchine con parecchi core (8 è 
la norma) rendono la compressione estrema non più così sconveniente rispetto 
ad un tempo.


 
http://planet.debian.net/cgi-bin/search.cgi?terms=jgoerzen
Non puoi generalizzare, ci sono casi in cui lo spazio conta molto, altri 
in cui sei tirato di cpu e/o ram, etc, etc..
Per esempio, per le distribuzioni le dimensioni del pacchetto finale 
conta molto:
pacchetti più piccoli = più pacchetti x supporto o meno supporti per lo 
stesso numero di pacchetti.
Lo stesso per discorso per FTP, i vari mirror che oltre al guadagno 
sullo spazio, hanno anche quello sulla banda.
Guadagno che nella maggior parte dei casi vale anche per l'utente 
finale.
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 l'obiettivo. Senza contare che l'uso di compressori paralleli 
Hai almeno scorso i numeri che ho fornito, vero?

 Non puoi generalizzare
Naturalmente. Se per te guadagnare il 36% di spazio e' vitale, a scapito di
22 VOLTE il tempo di elaborazione, fai pure. 

 22 VOLTE il tempo di elaborazione, fai pure. 
Per me lo sarebbe.
Se io dovessi scaricare l'ultima versione di qualche distribuzione, non
mi importa se gli sviluppatori hanno impiegato 30 giorni per creare i
pacchetti compressi, mi interessa però il fatto che la posso scaricare
in 15 minuti anzichè 1 ora, e mi interessa il fatto che posso salvarla
per intero su un cd anzichè 10.
Stessa cosa per i backup remoti.
Preferisco perdere 1 ora a comprimere e 10 minuti ad inviare file in
remoto tramite ADSL, piuttosto che perdere 1 secondo di compressione
e 1 ora di invio, durante il quale mille cose possono andare storte
sulla linea ADSL.

 per intero su un cd anzichè 10.
L'uso di computer non giustifica l'ignoranza in aritmetica. Non mi risulta 
esista compressione di un fattore 4, specie di un file gia' ampiamente 
compresso - sapevi che i pacchetti delle distribuzioni sono compressi in 
partenza?
Se tu poi vuoi scaricarlo in 40' anziche' 1h e decomprimerlo poi in 10 
giorni, accomodati. Chi te lo impedisce?

 giorni, accomodati. Chi te lo impedisce?
Be, io preferisco scaricare nel minor tempo possibile i file per poi
eventualmente elaborarli con calma sul mio computer.
Sostanzialmente per tre motivi:
1) e' molto più probabile, di almeno svariati ordini di grandezza
(visto che la matematica ti piace tanto) che ci sia un problema sul
collegamento internet tra me ed il server rispetto ad un problema sul
mio pc. Per cui prima scarico il file, minori sono le probabilità che
esso mi arrivi corrotto, che il trasferimento non vada a buon fine, bla
bla bla
2) meno roba da scaricare, meno tempo che impiego io a scaricare e di
conseguenza potrei ottenere lo stesso file anche con connessioni meno
performanti quando magari non sono ne in casa ne in ufficio
3) potrei tenere il mio file prerito anche nella memoria interna del mio
cellulare e portarlo sempre con me, per decomprimerlo solo quando
necessario, senza dover tutte le volte girare con dei DVD o chiavette
usb da 8 o più giga.
E poi, ripeto, son solo esempi. Semplicemente, come è già stato detto,
non puoi generalizzare dicendo che comprimere così tanto non ha senso.
Ci sono almeno 2-3 casistiche in cui la compressione è preferita
rispetto alle performance.

 giorni, accomodati. Chi te lo impedisce?
Be, io preferisco scaricare nel minor tempo possibile i file per poi


 Hai almeno scorso i numeri che ho fornito, vero?
Sì, e non ci trovo compressori paralleli.... che sia una dimenticanza.


 E cioe' che comprimere molto e' una follia anche con le cpu odierne.
Personalmente non capisco una cosa: sei rimasto scottato dal fatto che
tutti i compressori non ti hanno fatto ottenere i risultati che ti
aspettavi? Credevi di riuscire a comprimere un file di 1.2Gb in meno di
10Mb[1] ? Beh, penso che tu non abbia capito molto di come funziona la
branca della compressione software...
Enrico
[1] cosa che mi e` realmente successa. Ovviamente barai, il file da .2Gb
era praticamente il dump sql di una tabella molto grande e quindi era
praticamente identico dall'inizio alla fine

 rispetto alle performance.
che poi e' quello che dice il tizio dell'articolo.
Se deve fare il backup preferisce il tempo di compressione minore
rispetto alla dimensione del risultato
Se deve fare un pacchetto che deve essere scaricato da centinaia di
persone al giorno allora la dimensione del risultato e' preponderante.
Poi ovviamente ci sono le vie di mezzo: se devi backuppare su un tape
(o su remoto) allora magari preferisci una dimensione minore rispetto
ad un tempo di compressione un po' piu' alto.
Ciao Jack

 10Mb[1] ? 
Non ho sottomano un log bello ciccione per fare i test,
ma mi sembra di ricordare che con bzip riesci a comprimere,
spesso, un log di un fattore 3 o addirittura 4.
Non � la prima volta che vedo log da svariati giga finire a meno
di 500MB. E ne son sicuro al 1000%, dato che proprio grazie a
questa 'caratteristica' nei serverini virtulai tengo molto meno
spazio a disposizione nella partizione di log rispetto a quanto
facevo originariamente.

 Be, io preferisco scaricare nel minor tempo possibile
Ed usare la cpu per dieci giorni. Benissimo, peggio per te. 
Di nuovo, chi te lo impedisce? Devi fare un compromesso, se per te e' 
accettabile OK. Ovviamente dubito fortemente ci sia un altro che accetti 
un assurdo del genere.

 Sì, e non ci trovo compressori paralleli.... che sia una dimenticanza.
Impara a leggere. Poi torna qui a discutere.

 59474200 2009-09-16 08:36 test.txz
Ora spiegalo a qualche zipgenio che pretende di interloquire qua. Altro 
che tempi biblici.

 spesso, un log di un fattore 3 o addirittura 4.
mmmh... da me: log di una settimana: 120GB. Log di 6 mesi in bzip2: 120GB.
-- 
Vide

 mmmh... da me: log di una settimana: 120GB. Log di 6 mesi in bzip2: 120GB.
Eh...
Giornalieri:
skull@logserver:/...$ ls -lh *postfix*
-rw-r----- 1 root staff  112M Sep  2 00:00 20090901-postfix-log.bz2
-rw-r----- 1 root staff  103M Sep  3 00:00 20090902-postfix-log.bz2
-rw-r----- 1 root staff  102M Sep  4 00:00 20090903-postfix-log.bz2
-rw-r----- 1 root staff  110M Sep  5 00:00 20090904-postfix-log.bz2
-rw-r----- 1 root staff   91M Sep  6 00:00 20090905-postfix-log.bz2
-rw-r----- 1 root staff   87M Sep  7 00:00 20090906-postfix-log.bz2
-rw-r----- 1 root staff  105M Sep  8 00:00 20090907-postfix-log.bz2
-rw-r----- 1 root staff  103M Sep  9 00:00 20090908-postfix-log.bz2
-rw-r----- 1 root staff  103M Sep 10 00:00 20090909-postfix-log.bz2
-rw-r----- 1 root staff  1.2G Sep 11 00:00 20090910-postfix-log
-rw-r----- 1 root staff  1.2G Sep 12 00:00 20090911-postfix-log
-rw-r----- 1 root staff  1.2G Sep 13 00:00 20090912-postfix-log
-rw-r----- 1 root staff 1011M Sep 14 00:00 20090913-postfix-log
-rw-r----- 1 root staff  1.3G Sep 15 00:00 20090914-postfix-log
-rw-r----- 1 root staff  1.4G Sep 16 00:00 20090915-postfix-log
-rw-r----- 1 root staff  1.5G Sep 17 00:00 20090916-postfix-log
-rw-r----- 1 root staff  1.3G Sep 18 00:00 20090917-postfix-log
-- 
http://bofhskull.wordpress.com/

 giorni, accomodati. Chi te lo impedisce?
Minchia, sei tornato di nuovo, morpher spocchioso (ormai ho perso il conto 
dei nick che hai utilizzato, ma la saccenza nei tuoi post è sempre la 
stessa).
-- 
Vide

 Impara a leggere. Poi torna qui a discutere.
Ma hanno aperto le gabbie degli zoo??? Tutto d'un tratto salta fuori da 
it.scienza.matematica una scimmia che pretende di predicare il vangelo dei 
compressori...
Invece di predicare le tue granitiche quanto inutili certezze sarebbe meglio 
che facessi qualche esperienza *reale* fuori dall'università...


>>> Tu non hai mai fatto alcun confronto sulle compressioni, vero?
come a dire "non dire cazzate se non sai quello che scrivi"
io ho fatto i test e sostanzialmente ho ragione e te ti aggreghi per dare contro ad un altro?
Comunque li ho rifatti:
root@roberto:/usr/src# for i in gzip bzip2 xz;do time cat test.tar |$i -9 -c>test.$i; ls -l -h test.$i; done
real    0m58.125s
user    0m57.228s
sys     0m0.755s
-rw-r--r-- 1 root root 112M 2009-09-18 17:42 test.gzip
real    2m0.424s
user    1m59.383s
sys     0m1.041s
-rw-r--r-- 1 root root 93M 2009-09-18 17:44 test.bzip2
real    7m1.383s
user    6m58.858s
sys     0m2.131s
-rw-r--r-- 1 root root 57M 2009-09-18 17:51 test.xz
tempo 7 volte superiore a fronte di una compressione quasi doppia (verso il venerando gzip)
Sicuramente hanno avuto ragione in slack per i repository.. certo che se uno vuol fare compressione veloce non è da utilizzare
Con switch -1:
root@roberto:/usr/src# for i in gzip bzip2 xz;do time cat test.tar |$i -1 -c>test.$i; ls -l -h test.$i; done
real    0m12.509s
user    0m11.812s
sys     0m0.703s
-rw-r--r-- 1 root root 131M 2009-09-18 17:52 test.gzip
real    1m20.832s
user    1m19.306s
sys     0m1.067s
-rw-r--r-- 1 root root 108M 2009-09-18 17:54 test.bzip2
real    0m56.287s
user    0m55.386s
sys     0m0.828s
-rw-r--r-- 1 root root 103M 2009-09-18 17:55 test.xz
Per la cronaca il pupo di partenza è di
root@roberto:/usr/src# v -h test.tar
-rw-r--r-- 1 root root 404M 2009-09-16 08:00 test.tar


 milioni di file. 
vado di tar.... domani (di domenica) si parte e non si sa quando si
arriva. Vi farò sapere quanto avrà impiegato.
La conclusione è stata:
il dd ha il solo inconveniente che non consente un eventuale restore
selettivo. Ma potrebbe andar bene nel mio caso... ma i miei colleghi
hanno iniziato a palesare dubbi.
dump è fuori discussione perché non ha già funzionato una volta e non
ho tempo per fare test.
ho fatto un test con 'star' facendo una backup della /usr. Il risultato
è stato: 13 con tar, 12 minuti con star. Insomma leggermente più
veloce, ma mi cambia poco (nel caso di dump era 10 o 20 volte più
veloce....)
pax dopo alcuni test mi è sembrato addirittura più lento di tar.
cpio dovrebbe essere performante come pax (se non sbaglio).
rsync, sarebbe stata la soluzione migliore, ma non mi consente di
comprimere al volo e non posso usarlo.
partimage non mi vede i volumi LVM
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 partenza?
Sicuro? Vorresti dire che il tar.gz del vanilla della slack 13 non è un 
archivio tar poi compresso col gz?
Se ne impara ogni giorno una nuova


Giusto per qualche ulteriore ragionamento:
Il file di test è il tar di una /usr di un server
-rw-r--r--  1 root root 331120640 2009-09-18 18:08 test.tar
# time gzip -c test.tar > test.tar.gz
real	0m17.713s
user	0m17.393s
sys	0m0.288s
-rw-r--r-- 1 root root 124061041 2009-09-18 18:17 test.tar.gz
# time bzip2 -c test.tar > test.tar.bz2
real	0m41.064s
user	0m40.831s
sys	0m0.208s
-rw-r--r-- 1 root root 111219729 2009-09-18 18:09 test.tar.bz2
# time pbzip2 -p 1 -c test.tar > test.tar.pbz2
real	0m42.455s
user	0m42.091s
sys	0m0.360s
# time pbzip2 -p 2 -c test.tar > test.tar.pbz2
real	0m21.534s
user	0m42.575s
sys	0m0.440s
# time pbzip2 -p 4 -c test.tar > test.tar.pbz2
real	0m11.230s
user	0m44.235s
sys	0m0.464s
Il file di output in tutti i casi è:
-rw-r--r--  1 root root 111574132 2009-09-18 18:12 test.tar.pbz2
Quindi circa il 30% di tempo meno di gzip comprimendo circa il 10% in più.


 arriva. Vi farò sapere quanto avrà impiegato.
Ti manca di provare dar !


 selettivo.
Sarebbe il dd di un'intera partizione?
Montando l'immagine in loopback potresti anche fare il restore
dei singoli file...

 sapere cosa succede :)
Semplice, basta vedere Facebook (anche se li ci sono ottimizzazioni
pesanti). Personalmente non ho mai superato il paio di milioni di record
al giorno su Oracle (datawarehouse), ma purtroppo mi sono un po' fermato
da quel punto di vista
Enrico
P.S. Fai nomi. Sapere di quale database si tratta puo` aiutare molto a
capire come risolvere il problema

 spesso, un log di un fattore 3 o addirittura 4.
Anche di pi�.
ls -l unweb.log.bz2
-rw-r--r--  1 root root 22112562 Jun 10 11:54 unweb.log.bz2
bzcat unweb.log.bz2 |wc -c
567231103
567231103/22112562 = 25.652
-- 
ValeRyo
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 Anche di piï¿œ.
Sarebbe interessante sapere cosa ne pensa il nostro amico,
dato che dice di non aver mai detto di aver visto un compressore
comprimere di un fattore 4. Quï¿œ a quanto pare si comprime di un
fattore 25.
Che abbia pisciato fuori dal vaso per fare lo sborone?

 Che abbia pisciato fuori dal vaso per fare lo sborone?
Non so, magari in astratto e su basi statistiche ha ragione lui,
ma in pratica si raggiungono fattori di compressione molto
elevati. Mi basta pensare ai messages pieni di cron cron login
cron cron che comprimo tranquillamente ad un 40esimo dell'originale.
Se lui pensa a tar di cartelle immagini � ovvio che comprima
del 2% se gli va bene, solo che a nessuno verr� mai in mente
di comprimere una cosa del genere.


 ha scritto:

purtroppo il backup sarà gzippato, e non ho spazio per decomprimerlo.


 
Credibilissimo, però non senza se e senza ma.
Tu come prima operazione hai fatto quella con il "gzip".
La seconda operazione e le altre utilizzeranno informazioni in cache
della CPU.
Hai fatto questi test in stretta sequenza, sulla stessa macchine?
Lo dico perché anche a me, quando ho fatto "star" vs. "tar", erano
venuti fuori dei risultati sballati, quindi ho rifatto il
test,lanciandolo in parallelo su macchine diverse, aventi lo stesso
hardware... e i risultati sono cambiati.


 Decido cosi' di investire 100k euro in cpu, o spazio dischi?
100k euro in CPU, 10 giorni per decomprimere un file al posto di 40
minuti .... i tuoi numeri sono a dir poco iperbolici :)


 capire come risolvere il problema
il DB si chiama: Addamark.
Fa parte di una suite che si chiama Sensage.
Lo storage si chaima Centera.


 Fa parte di una suite che si chiama Sensage.
Trovato. Sembra un RDBMS destinato ed ottimizzato alla gestione di
grandi moli di dati simile a Teradata. Carino, ma non conosco (ne voglio
conoscere, come minimo 'sto coso costa tanto quanto l'ammontare della
rivendita dei miei organi al mercato nero)
Enrico

 consente la cancellazione e ci accedi solo tramite l'API del prodotto.
Piu` che file system a blob mi sembra che non vi sia alcun file system,
cosa molto comune nelll'implementazione di un database. Resta comunque
valido il discorso che facevo piu` avanti nel post: e` molto piu` sicuro
un dump che la copia dei datafile
Enrico

 
Si. Infatti, in prima istanza (3 mesi fa) avevo fatto così (dd in pipe
con gzip). Però avevo usato un fattore di compressione basso e ho
riempito la partizione di uno dei 15 server.... allora non ho voluto
riprovare.
Lo svantaggio (come ho risposto a wiplash) è che l'immagine gzippata
non la posso montare in loopback, e quindi non posso fare un eventuale
restore selettivo. Devo anche ammettere che un restore selettivo, con
un milione di file serve veramente a poco ;)


 con gzip). 
Nono, con dump intendo l'esportazione dei dati per mezzo degli appositi
comandi del database, e non la copia dei dati presenti sul disco. Per
intenderci, sto dicendo di usare l'equivalente di pgdump o di mysqldump
per Addamark
Enrico

 Eh...
Il mio bizippa meglio :P
-- 
Vide

 minuti 
Dove avrei parlato di 100k di cpu per 40'? Di che accidenti stai parlando?

 archivio tar poi compresso col gz?
Veramente ho detto proprio questo. L'italiano, questo sconosciuto.

 Minchia,
Un monopensiero.  Vai a giocare in autostrada, da bravo.

 Ma hanno aperto le gabbie degli zoo?
Probabile, se ti fanno scrivere liberamente.
Ora vai a giocare con la corrente, da bravo minus habens.



E tutto questo malloppone per dire "No, e' come dicevi tu sin dall'inizio"?
Ma questo lo sapevo da tempo. E chiunque lo poteva desumere da quel link.
In breve: comprimi meglio aspettando un ordine di grandezza in piu'.
Considerato il prezzo dei dischi vs prezzo di una cpu piu' veloce di un 
fattore 2 non mi pare una gran furbata.

 una cpu piu' veloce di un fattore 2 non mi pare una gran furbata.
Tu ragioni come se si comprimesse per lavoro.
Beh, il mio lavoro non � 'comprimere file', ma 'amministrare sistemi'.
Io lancio bzip2 invece di gzip alle 18 prima di uscire dall'ufficio,
e mi trovo la met� dello spazio occupato la mattina dopo.
Risparmio non solo spazio disco, ma anche il mio tempo nell'archiviare
tali file, nel gestirli, nel recuperarli quando necessario.
E in cambio del tempo che il mio processore avrebbe passato in idle.


 fattore 2 non mi pare una gran furbata.
E tu per scrivere queste 2 stronzate dovevi quotare
per intero 4 persone?
Bel quoting, davvero.

 E in cambio del tempo che il mio processore avrebbe passato in idle.
Sono profondamente amareggiato :-) dal fatto che nessuno abbia provato 
7z. Comunque un altro fatto importante, a volte piu` importante, oltre 
al tempo di compressione e utilizzo di CPU in questa fase e` quello di 
decompressione e utilizzo di CPU in quella fase, li` come siamo messi?
Andrea

 7z
7-Zip e` un formato di archiviazione che usa nativamente il formato di
compressione LZMA. Quest'ultimo, se non sbaglio, e` stato citato un paio
di volte nel thread, di conseguenza, si puo` dire che 7-Zip e` stato
tranquillamente provato
Enrico

 giorni, accomodati. Chi te lo impedisce?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Fashion is a form of ugliness so intolerable that we have to alter it
every six months.
		-- Oscar Wilde


Non fare il girafrittate..
IO ho fatto come esempio la maggior compressione (e quindi minor spazio 
disco e banda utilizzati in download) per la slack (di un 30%) e TU hai 
risposto che le distribuzioni sono già compressi in partenza.
Abbi l'onestà intellettuale di dire "vabbè, ho scritto una cosa ma ne 
pensavo un'altra"


 decompressione e utilizzo di CPU in quella fase, li` come siamo messi?
Un test veloce: 800Mb, compressi in 20, bzcat li ha aperti in 23 secondi
e cat in 13.


 pensavo un'altra"
Potrebbe anche canticchiare:
"ho detto proprio una ca..
una vera cazza...
una grande...
gigantesca...
strepitosa cazzata....!!!!"
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Do
PLONK.
Yes, I did it.

 Non fare il girafrittate..
E` un troll, non puo` comportarsi diversamente
Enrico