Newsgroup: it.comp.os.linux.sys
Titolo: differenze fra copie con du

Uso backintime per il backup del mio desktop..
Per curiosità ho fatto un du su una subdir della mia home dove ci sono 
solo files personali non modificati di recente, e la corrispondente dir 
del backup odierno sul disco di backup...
Il risultato era diverso di qualche decina di bytes, provato un diff -qr 
fra le due dir e non è uscita nessuna differenza ...
Googlando "du wrong size" si trovano diverse "conferme" della 
possibilità di questo, ma resto comunque un po' dubbioso...
backintime usa rsync che da quanto ho capito effettua comunque una 
verifica della copia, e inoltre ho verificato io "a manina" con diff...
Direi che qualsiasi sia il motivo posso ritenermi sicuro vero ?


Una possibile causa è che se du somma anche le dimensioni delle
directory (non lo so), potendo avere dimensioni diverse, fanno sballare
il calcolo.
Questo perché una directory aumenta la propria dimensione all'aumentare
del numero di file al proprio interno, ma non diminuisce se alla loro
cancellazione.
Ciao

 directory (non lo so), 
Ecco, se non lo sai stai zitto così eviti di scrivere str...upidate

 ...
In genere du' ls e wc riportano dimensioni diverse poiché sono fatti in 
maniera diversa per conoscere aspetti diversi.
In particolare du  conta lo spazio sul disco realmente occupato da 
un file, che è un multiplo della dimensione del blocco, ls riporta la 
dimensione apparente in byte del file (includendo i blocchi non riempiti
ed escludendo lo spazio non riempito alla fine dell'ultimo blocco) così come
memorizzato nel filesystem e wc conta i caratteri del file.
Non conoscendo il filesystem e gli esatti comandi che hai dato e poiché tu 
NON HAI POSTATO L'OUTPUT DELLA SHELL, non posso dire di più.

 ha scritto:

le directory ad esempio si frammentano.
root@yasna:/# mkdir pippo; du -sh pippo
4,0K	pippo
root@yasna:/# du -sh lost+found/
16K	lost+found/
sono entrambe vuote, però hanno dimensioni diverse. La seconda è 4
volte più grande.
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 ha scritto:

si però, du di una directory vuota non da zero, ma ti da la stessa
dimensione che ottieni con ls su quella directory, e se la directory è
frammentata ti darà una dimensione maggiore. A me, a occhio, non mi
pare che abbia scritto un str...upidata.


 pare che abbia scritto un str...upidata.
Però l'opener ha fatto una domanda sulle dimensioni dei FILE e un altro 
ha risposto che du somma anche le dimensioni delle directory.
Ma che ci azzeccano le directory con le dimensioni dei file? 
A maggior ragione che ci azzeccano le directory frammentate?

 ha scritto:

aspetta, l'OP parla di "du" lanciato su una subdir. Mo' capiamo insieme
cose delle quali normalmente non ce ne frega nulla.
$ mkdir -p a/b/c/f/
$ du -sh a
16K	a
Cioè, "du" effettivamente somma la dimensione delle dir: 4+4+4+4
Se la dir è frammentata, come ho fatto vedere prima, du riporta
effettivamente dimensioni maggiori. 
... e siccome extX non si può ancora deframmentare, per deframmentarla
la devi creare ex novo, come nel caso del rsync.


 Cioè, "du" effettivamente somma la dimensione delle dir: 4+4+4+4
Se dai l'opzione --summarize è normale che du mosti SOLO LA SOMMA.
L'opener ha detto chiaramente di aver dato ``diff -qr'' che, come senz'altro 
NON saprai, quando passi directory come argomenti  confronta due a due 
i file omonimi contenuti in esse.
Che ci appizzano le directory con i confronti tra file?
Che ci appizzano le directory frammentate?
Che ci appizzano i totali riportati da du?
 

 Che ci appizzano i totali riportati da du?
Mi rispondo da solo: L'opener ha riscontrato differenze proprio in 
questi totali quindi la frammentazione interna dei file non ci appizza 
niente mentre c'entra la frammentazione interna delle directory.




that's it ... come avevo capito inizialmente. 
mo' vediamo se funziona anche il newsreader sul tablet :-)

 NON HAI POSTATO L'OUTPUT DELLA SHELL, non posso dire di più.
Non c'è output significativo di du --total --summarize MIADIR a parte il 
numero, diverso nei due casi... diff -qr non trovando niente di diverso 
non ha output...
Spero che visto che rsync non ha dato errori, e diff -qr neanche, 
sull'integrità dei dati si possa stare tranquilli (sgrat sgrat)
Paolo

 non ha output...
Ok, io avevo capito male. È molto importante riportare esattamente i 
comandi dati (basta un copia e incolla) proprio per evitare gli equivoci 
come quello in cui sono caduto io. Mi scuso.
In effetti la risposta già ti è stata data: du include anche lo spazio 
occupato dalle directory che è diverso nei due casi ance se poi queste
contengono gli stessi file. Queste sono diverse perché  è molto 
importante la storia di come hai riempito la directory. Mi spiego meglio:
Quando usi una directory, scrivi, cancelli, riscrivi, copi, modifichi e 
ricancelli molti file quindi la tua directory sarà molto intricata e, 
potenzialmente, avrà una dimensione superiore ai dati effettivamente
usati. Quando invece copi quella stessa directory (con tar, rsync,
cpio o altro), la directory sarà più ordinata e compatta; conterrà gli 
stessi file ma sarà totalmemte diversa dalla directory origine e potrà
avere una dimensione minore.
L'unico punto che non capisco (ma potrebbe essere un refuso) è questo:
tu hai detto chiaramente che le differenze sono di poche decine  byte 
ma se nel caso esaminato le differenze dovrebbero essere multipli 
della dimensione del blocco* e quindi di poche decine di KiBi.
* dipende ovviamente dal filesystem, poiché alcuni filesystem usano 
strutture più complesse per la directory.


scusa mio guru e padrone.
non mi permetterò mai più di parlare.

 AddÃ¬  giovedÃ¬ 31 marzo 2011 23:22 mallin.shetland scrisse:

ho letto bene? stiamo quindi parlando di frammentazione delle directory?

 copi, modifichi e ricancelli molti file quindi 
backintime (del quale parla l'OP e che uso pure io in ambiente desktop)
crea degli snapshot, tramite rsync. 
La prima volta crea i file ex novo. Per i successibi snapshot, crea
degli hardlink per i file esistenti e aggiunge solo i nuovi file.
Ad esempio, questo file che io non ho mai modificato è hardlinked 14
volte:
-r--r--r--  14 root     root    1343 2007-01-09 19:39  wodim.conf
IMHO il problema è sempre la frammentazione:
# ll -d /etc/
drwxr-xr-x 246 root root 20480 2011-04-01 12:14 /etc/
# ll -d /media/IomegaEXT4/backintime/20110326-153311/backup/etc
drwxr-xr-x 245 root root 16384 2011-03-26
15:28 /media/IomegaEXT4/backintime/20110326-153311/backup/etc
E infatti, la copia sul disco di backup è sempre più piccola:
# du -s /media/IomegaEXT4/backintime/20110401-124340/backup/etc
164908	/media/IomegaEXT4/backintime/20110401-124340/backup/etc
root@yasna:/media/IomegaEXT4/backintime/20110401-124340/backup# du 
-s /etc
165304	/etc
VA DETTA COMUNQUA UNA COSA ALL'AMICO OP CHE HA APERTO IL THREAD.
Backintime, per defaul, esclude dal backup i file ".*" (non so se lui
ha lasciato l'impostazione predefinita).
In questo caso, io in /etc, ho una directory /etc/.java
e sommandola al precedente computo assottiglierebbe la differenza a 
164940 contro 165304


 ha scritto:

IMHO si. Ho appena finito di sviscerare backintime (che uso pure io
con regolarità) e il problema sembrerebbe essere proprio quello.
Per quanto riguarda gli hardlink di backintime, essendo su directory
diverse, du li calcola come normali file.



Le nuove versioni per fortuna non escludono di default le directory 
nascoste (ed č meglio cosě, la cosa evita un sacco di guai)
Per le directory avevate ragione, ho analizzato le dimensioni dei files 
e sono tutte uguali, mentre sono diverse quelle di alcune directory (non 
di tutte)
la differenza č di qualche decina di kb , non di bytes, scusate la svista.
A questo punto, tutto torna, almeno imho.
Grazie a tutti
ps:
quando avevo fatto una semplice copia con cp, du aveva mostrato la 
stessa dimensione prima e dopo, ma si vede che rsync (o il modo in cui 
backintime lo usa) fa qualcosa di leggermente diverso.
Non si tratta di hardlinks, perchč quella directory prima era altrove, 
quindi per backintime era "tutta nuova" da backuppare...