Newsgroup: it.comp.os.linux.sys
Titolo: rsync: dimesioni superiori all'originale

Ciao all,
stavo smanacciando con rsync e mi sono accorto di una cosa, il
sistema "copiato" risulta più "grosso" dell'originale.
Qualche esempio sull'output di du -sk
DIR     |       ORIGINALE       |       COPIA
bin     |       7470            |       7580
lib     |       133331          |       138064
sbin    |       7944            |       9020    
Di diverso sicuramente c'è il fs: reiser->ext3
IMHO le possibilità sono due:
1) canna du
2) effettivamente etx3 gestisce peggio lo spazio (directory index
impostato..)
Se avete a cuore le sorti di quella povera partizione formattata ext3,
ditemi che non è l'ipotesi 2. La riformatto in reiser senza pensarci su
un secondo di troppo :)
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 impostato..)
3) non hai copiato i file come sparse. Ricrea il fs ext3 e riprova usando
l'opzione -S di rsync.
-- 
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.

 2) effettivamente etx3 gestisce peggio lo spazio
A prescindere da quanto dica du, non esiste il minimo dubbio:
reiserfs, XFS e JFS in questo sono *molto* migliori di ext3. XFS e
JFS, però, sono filesystem che si *deteriorano* coll'uso (anche se
lievissimamente, dal punto di vista dello spazio): cioè se creo dei
file, e poi li cancello, il fs non torna esattamente com'era prima.
Cfr. 
http://www.debian-administration.org/articles/388
Formattando una partizione in ext3  lo spazio disponibile è di
diversi punti percentuali inferiore a quello diponibile con reiserfs
(siamo sul 6-7% circa).
Reiserfs, tanto per fare un esempio, può riunire molti piccoli file
(o molte code di file) in un solo blocco. Gestisce molto meglio le
directory, quando queste contengono moltissimi file.
Altri articoli interessanti, benché un po' datati:
http://navindra.blogspot.com/2004/10/kde-dot-news-ext3s-miserable-failure.html
http://www.linux.com/articles/31939
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

 usando l'opzione -S di rsync.
Con du -sk, non è cambiata una virgola..
Ho riformattato la partizione. 
Abilitato il dir_index
rsyncato con
rsync -avS --delete --exclude-from=/tmp/rsexclude.txt / /mnt/backup/
du riporta le stesse identiche dimensioni (quelle riportate nel primo
post).
Esempio più dettagliato:
/bin/date 52->56
Però con du -sb le dimesioni sono identiche: 51768 che è lo stesso
valore riportato da ls..
Mah..


 /bin/date 52->56
Hai usato blocchi da 8k al posto che da 4k?


 Hai usato blocchi da 8k al posto che da 4k?
Io non ho specificato nulla. L'unica opzione che ho passato a mkfs è
stata "-m 1".
fsck restituisce:
/dev/sdb1: 293788/2443200 files (0.2% non-contiguous), 3525969/4885760
blocks
Visto che la partizione è di 20G, i blocchi dovrebbero essere da 4,
giusto ?
Comunque è mica la prima volta che "litigo" con du.
Per esempio adesso per du /bin è di 8Mb, konqueror riporta 7,1


> Per esempio adesso per du /bin è di 8Mb, konqueror riporta 7,1
forse il problema sono le unita' di misura, con le quali c'e' un po' di
confusione
kbyte = 1000 bytes
kibytes = 1024 bytes
http://it.wikipedia.org/wiki/Prefissi_per_multipli_binari
oppure arrotondamenti al settore fisico del disco ( 512 bytes ) o al blocco
( 4 kbytes ), oppure ancora, specie per le directory, uno strumento riporta
la somma delle dimensioni arrotondate, l' altro la somma precisa dei
singoli files.
prova "du -B --si" su originali e copie
vp

 directory, quando queste contengono moltissimi file.
Si chiama "riduzione della frammentazione interna".
Se in ext3 hai blocchi da 4 Kb e un file da 4097 byte, vengono occupati 
due blocchi da 4 Kb, di cui uno contiene solo un byte.
In reiser gli altri 4095 byte vengono usati per un altro file.
Questo ha il vantaggio di sfruttare meglio lo spazio su disco, ma col 
rischio di aumentare la frammentazione (interna ed esterna) del fs.
Detto questo, io ho avuto grosse rogne con reiser (fs sputtanato e 
irrecuperabile, reiserfschk che andava in segfault. Tre volte.) e 
prestazioni deludenti (minuti di attesa al boot per il mount, non per il 
check), non bilanciate da reali vantaggi operativi (il disco era comunque 
piu` veloce della rete, e il gap prestazionale e` stato ridotto a zero da 
versioni successive del "driver" ext3 nel kernel), quindi tendo a 
sconsigliarlo.
Bye.

 puo` configurare.
Ah, ero convinto che reiserfs ne destinasse 32, ext3 solo 4 di
default. Sicuramente mi sbagliavo.


 rischio di aumentare la frammentazione (interna ed esterna) del fs.
Diciamola tutta. Cito dal web:
| If a file is
| smaller than a filesystem block, it is actually stored in the binary tree itself instead
| of being pointed to. Retrieving the data for these files therefore takes no more time
| than is required to locate them in the b-tree, which makes ReiserFS an excellent
| choice for filesystems in which large numbers of small files are constantly being
| created and deleted, such as mail directories or mail servers.
| ReiserFS also provides other optimization that can lead to dramatic space savings
| compared to traditional filesystems.
| When a file is stored on a filesystem, filesystem blocks are allocated to actually
| store the data that the files contain. If you had a block size of 4K, but wanted to
| store a file of 6K on the disk, you would be wasting 2K of disk space because a block
| belongs to one file only and in this case you would have to occupy two, wasting 2K
| and therefore not optimally using the space. ReiserFS can also store these fragments
| in its b-tree by packing them together, which provides another way of minimizing
| disk space consumption in a ReiserFS filesystem.


 sempre, e son contento.
Infatti, anche io lo azzero sulle partizioni che non sono /, /var e poche 
altre.
 
Bye.

 Uhm... no. Al termine della formattazione la differenza e` proprio li`.
Provando qualche minuto fa su una partizione da 24,42GB circa ho
ottenuto i seguenti risultati:
mkreiserfs /device -> liberi 24,39GB
mke2fs -j -m0 -O dir_index,filetype,sparse_super -T largefile /device -> 24,2GB
mke2fs -j -m0 -O dir_index /device -> 23,87GB
con un vantaggio per reiserfs che va dall'1% scarso al 2%. Mi sono
stupito: mi aspettavo un po' di più, sinceramente. Mi sembra di
ricordare che, su dischi di maggiori dimensioni, io avessi
sperimentato differenze superiori, in accordo con quanto mi sembra
d'aver sempre saputo (che poi, se la grossa differenza fosse davvero
dovuta alla riserva per root, sarebbe davvero stranissimo averla
presentata in quel modo nei test linkati).
Tanto per tirarmi la zappa sui piedi, però, segnalo questo link:
http://linuxgazette.net/122/piszcz.html
Contraddicendo clamorosamente quanto sostenevo e quanto sono certo di
aver letto in molti altri posti (mica uno), e il test appena fatto,
ext2/3 paiono sopravanzare reiserfs (naturalmente nonostante il fs
sia stato creato colla riserva del 5%, vien preso in considerazione
anche quello spazio).
Mah carpiato...


 prova "du -B --si" su originali e copie
Ehmm "--si" ?!
Comunque ho provato con diversi valori, e per du sono sempre diversi:
dan@kailed:/mnt> du -B 512 backup/bin/date
112     backup/bin/date
dan@kailed:/mnt> du -B 512 /bin/date
104     /bin/date
dan@kailed:/mnt> du -B 4096 backup/bin/date
14      backup/bin/date
dan@kailed:/mnt> du -B 4096 /bin/date
13      /bin/date
Però:
dan@kailed:/mnt> du -sb /bin/date
51768   /bin/date
dan@kailed:/mnt> du -sb backup/bin/date
51768   backup/bin/date
questa combacia con ls e konqueror..
Boh..


 13      /bin/date
Idem. A naso sembra contare una dir in meno.. boh, possibile?
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 Idem. A naso sembra contare una dir in meno.. boh, possibile?
Bella domanda :)
