Newsgroup: it.comp.os.linux.iniziare
Titolo: Errore inspiegabile con du e ls

Il file seguente da' luogo a un comportamento che mi sembra
anomalo dei comandi du e ls, eccolo:
[video]dalet_$: du -h VTS_01_1.VOB
2,1M	VTS_01_1.VOB
Invece e' un giga.
[video]dalet_$: du -h
845M	.
Tutta la directory e' piu' di 6 giga, non 845 mega.
[video]dalet_$: ls -lh
totale 845M
-rw-r--r-- 1 dalet users  12K 12-giu-11 21:54 VIDEO_TS.BUP
-rw-r--r-- 1 dalet users  12K 12-giu-11 21:54 VIDEO_TS.IFO
-rw-r--r-- 1 dalet users 1,9M 12-giu-11 21:57 VIDEO_TS.VOB
-rw-r--r-- 1 dalet users  88K 12-giu-11 21:57 VTS_01_0.BUP
-rw-r--r-- 1 dalet users  88K 12-giu-11 21:57 VTS_01_0.IFO
-rw-r--r-- 1 dalet users 9,4M 12-giu-11 21:45 VTS_01_0.VOB
-rw-r--r-- 1 dalet users 1,0G 12-giu-11 22:13 VTS_01_1.VOB
-rw-r--r-- 1 dalet users 1,0G 12-giu-11 23:19 VTS_01_2.VOB
-rw-r--r-- 1 dalet users 1,0G 12-giu-11 22:29 VTS_01_3.VOB
-rw-r--r-- 1 dalet users 1,0G 12-giu-11 22:34 VTS_01_4.VOB
-rw-r--r-- 1 dalet users 1,0G 12-giu-11 22:44 VTS_01_5.VOB
-rw-r--r-- 1 dalet users 1,0G 12-giu-11 23:19 VTS_01_6.VOB
-rw-r--r-- 1 dalet users  44M 12-giu-11 23:07 VTS_01_7.VOB
Anche qui il conto 845 mega e' lo stesso che riporta du, chissa'
cosa vuol dire.
[video]dalet_$: cat VTS_01_1.VOB > /tmp/pippo
[video]dalet_$: du -h /tmp/pippo
1,1G	/tmp/pippo
Adesso invece funzione, perche?!
[video]dalet_$: ls -lh /tmp/pippo
-rw-r--r-- 1 dalet users 1,0G 14-giu-11 19:31 /tmp/pippo
[video]dalet_$: ls -lh /tmp/pippo
totale 1,1G
drwx------ 2 root  root   16K 27-mag-11 22:56 lost+found
drwx------ 2 dalet users 4,0K 14-giu-11 13:58 mc-dalet
drwx------ 2 root  root  4,0K 14-giu-11 19:22 mc-root
-rw-r--r-- 1 dalet users 1,0G 14-giu-11 19:31 pippo
Dunque in /tmp funzionano normalmente entrambi: du e ls, bohh!
-- 
Saluti, Dalet

 Invece e' un giga.
Mai capitato con un video, ma non è che usi un file system
con lo "sparse file" attivo?
Cosa dice cat
/etc/mtab
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

/etc/mtab
eccolo, io stavo in /home/film/video (cioe' in /dev/sdb12)
/dev/sda3 / ext2 rw,errors=remount-ro 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
udev /dev tmpfs rw,mode=0755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0
/dev/sda5 /usr ext2 rw,nodev 0 0
/dev/sda6 /usr/share ext2 rw,nosuid,nodev 0 0
/dev/sda9 /home ext2 rw,nosuid,nodev 0 0
/dev/sda7 /var ext2 rw,nodev 0 0
/dev/sdb2 /tmp ext2 rw,nosuid,nodev 0 0
/dev/sda8 /home/zz ext2 rw,noexec,nosuid,nodev 0 0
/dev/sdb12 /home/film ext2 rw,noexec,nosuid,nodev 0 0
/dev/sdb14 /home/b14 ext2 rw,nodev 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0
-- 
Saluti, Dalet

 ...
Codesta cosa è dovuta a due fattori. Il primo è che ls 
riporta la dimensione apparente di un file mentre du 
riporta la dimesione reale di un file, ossia quanti blocchi
sul disco il file occupa veramente e questi due valori 
in genere differiscono. Il secondo fattore è che i 
filesystem Unix (ma anche iso9660 e udf) supportano
i file sparsi, cioè un file che contiene buchi.
Piccola spiegazione.
Inizia a scrivere i primi dieci caratteri di un file. 
Il sistema operativo scriverà i primi dieci caratteri ma
poichè può scrivere un numero intero di blocchi allora 
scriverà un blocco che in genere è 4096 caratteri i cui
primi dieci sono i caratteri che hai scritto tu ed i restanti
quattromila e rotti sono zeri.
Ora se fai ls ottieni che il file è lungo dieci caratteri
perché tu hai scritto ieci caratteri pero se fai du ottieni
la dimensione reale che è 4K poiché quel file occupa un 
blocco del disco di 4096 caratteri anche se usi solo dieci 
caratteri.
 
Ora ti sposto alla centomilionesima posizione e scrivi altri
dieci caratteri. Il sistema operativo calcola in quale blocco
deve scrivere il centomillesimo carattere e scrive i dieci 
caratteri in un blocco di 4096 dove, come prima,  i restanti
4086 sono zeri. Fa attenzione che il sistema operativo non 
si mette a riempire tutti i blocchi intermedi con zeri ma 
scriverà solo il primo e l'ultimo blocco e segnerà che tutti 
i blocchi intermedi sono un buco e non sono presenti sul
disco. Quindi, ripetiamolo, tu ottieni un file con un grosso 
buco al centro e dove sono presenti solo il primo e l'ultimo 
blocco.
Se ora fai ls ottieni che il file è lungo centomilioni e 
dieci caratteri mentre du si accorgerà del buco e ottieni
che il file è 8K poichè in realtà solo due blocchi sono 
realmente presenti, il resto del file è un buco.
Quando tu cercherai di leggere dei dati posti in un buco il
sistema operativo si accorgerà di essere dentro un buco
e ti restituirà tutti zero. Se viceversa cercherai di scrivere
in un buco allora il sistema operativo si accorgerà di essere
in un buco, saprà che in realtà quel pezzo di file non esiste,
allocherà un blocco libero, lo metterà nella giusta sequenza
e scriverà i tuoi dati e poi tutti zero.
Questo spiega il comportamento di cat. cat è un programma 
stupido, non si accorge dei file con buchi e quindi leggerà 
degli zeri e scriverà degli zeri. Il risultato finale è che in 
partenza hai un file con dei buchi ed alla fine cat ha copiato
un file senza buchi ma che contiene tutti zero.
Meglio quindi usare cp che almeno riconosce i file sparsi, 
ossia i file con buchi e che almeno puoi dare l'opzione di 
ignorare i buchi o di conservare i buchi.

ignorare i buchi o di conservare i buchi.
Si' bravissimo c'hai ragio' e' quasi vuoto devo averlo
copiato male dal dvd -- THX per tutte le info! lo vedo
con xine che dura solo qualche secondo.
E adesso ho fatto pure la controprova:
-- ho dato cp sovrascrivendolo in /tmp
-- c'ha messo un'istante a copiarlo (si vede che stava in
memoria)
-- du -h adesso mi dice 2,1 mega.
-- 
Saluti, Dalet

 giusta sequenza e scriverà i tuoi dati e poi tutti zero.
Belli i file con i buchi!
Un buco mette sempre allegria. Qualunquemente! :)
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
http://cleanenergy.harvard.edu/
 
http://spin.fh-bielefeld.de/
 
http://www.gpugrid.net/