Newsgroup: it.comp.os.linux.sys
Titolo: df

Scusate la domanda che appare banale ma forse non lo è e comunque mi 
inquieta non poco.
Noto con "df" che un server ha poco spazio, meno di quanto mi 
aspettassi, nella partizione che monta /var.
Vado in /var e do il comando: "du * -s": mi da un totale byte occupati 
minore rispetto a quanto dice df.
Non basta: cancello dei vecchi log di apache da /var/log: df continua a 
dire LA STESSA COSA: i byte occupati secondo lui non scendono. Secondo 
"du" invece sì.
Copio un file grande X in /var/log: df dice che lo spazio è diminuito di X.
Cancello questo file: df dice che lo spazio è aumentato di X.
FACCIO REBOOT: df ora dice lo spazio giusto, concorde con "du * -s".
La funzione disk_free_space() di php dice le stesse cose che dice df.
Il filesystem è ext3 su opensuse 10.
Domanda: com'è possibile che cancellando file vecchi di log, df non dica 
che lo spazio aumenta, e invece lo dice se faccio reboot?
Grazie.

 
bella domanda... la butto li... forse perche' certe cose non vengono 
'realmente' modificate sui dischi... non subito almeno...
riprova l'esperimento, ma dopo la cancellazione da il comando sync, e 
attendi qualche secondo... se ho ragione, facendo cosi', forzi la 
scrittura su disco, e la cosa dovrebbe essere piu' 'coerente'...

 che lo spazio aumenta, e invece lo dice se faccio reboot?
E facendo un sync invece di reboot?

 
Se non ricordo male, lo spazio di un file cancellato viene liberato
quando tutti gli handle sul file vengono chiusi

 quando tutti gli handle sul file vengono chiusi
Si, ci srarnno stati file descriptor collegati a processi morti.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 
ho provato a fare un po' di esperimenti per riprodurre il fenomeno, ma 
non mi succede...
credo sia a causa del IO_scheduler che  si utilizza... probabilmente uno 
tiene piu' roba in memoria e scarica blocchi maggiori a intervalli piu' 
lunghi...
mi piacerebbe sapere quale usi tu...
se hai un file in /boot che inizia con 'config'.... potresti passargli 
il comando
$ grep -C 10 -i "schedulers" /boot/config-2.6....
e postare l'output?
(io per la cronaca uso CFQ... c'e' anche Deadline e Anticipatory...)
se mi levi la curiosita', mi fai un favore
ciao

 
io ho provato a craere un file di mezzo mega random, entrarci con vim, 
da un'altra console cancellarlo, e nonostante sia ancora aperto con vim, 
df mi segna la differenza

 $ grep -C 10 -i "schedulers" /boot/config-2.6....
grep -C 10 -i "schedulers" /boot/config-2.6.18.2-34-bigsmp
CONFIG_STOP_MACHINE=y
#
# Block layer
#
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
Mi illumini su questa roba qua (anche con un link mirato)? Grazie.

 E facendo un sync invece di reboot?
Domani lo provo (ora da remoto preferisco non far esperimenti e vincere 
una notte in ufficio :-) ).

 
Mi sa che con vim non funziona perchč chiude l'handler.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa
scrittura, non so per chi, non so piů intorno a che cosa...
U. Eco

 
Dai un'occhiata qui
http://www.linux-archive.org/gentoo-user/143824-df-du-difference.html


 che lo spazio aumenta, e invece lo dice se faccio reboot?
Semplicemente, come dice Francesco Paolini, c'e` un processo che accede
al file. Se vuoi fare delle prove, metti in riproduzione un file mp3 e
poi cancellalo mentre viene ancora eseguito
Enrico

 
e' una questione (da quel che ho capito) leggermente diversa
dice che du e df danno valori diversi sulla partizione, ma non che non 
si aggiornano dopo un'operazione...

 
sai un modo per poter far la prova usando bash?

 Mi illumini su questa roba qua (anche con un link mirato)? Grazie.
in linux esistono tre modi diversi di scrivere i dati su disco, con 
prestazioni diverse a seconda dell'uso che si intende farne
quel file che hai greppato e' il file di configurazione con cui e' stato 
compilato il kernel
tra l'altro questa' e' un'altra delle cose che rende linux unico
il fatto di essere open source permette di ricompilarlo dai sorgenti, e 
quindi di 'riconfigurarlo' usando parametri diversi
 > CONFIG_DEFAULT_CFQ=y
da questa riga si vede quale IO_scheduler usi... e in effetti e' lo 
stesso che uso io
quindi forse han ragione quelli dell'altro post... e il file non veniva 
cancellato perche' altri processi lo usavano...
pero' non riesco a riprodurre il fenomeno... mah!

 
vero
provando con vim non succedeva... invece con un file audio e' molto evidente
e in effetti vim crea un altro file (.file.swp), e quindi probabilmente 
usa quello, e rilascia subito l'originale

Antonio Macchi ha scritto:

Si ma leggi anche dopo, in uno dei post seguenti.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 "du" invece sì.
Avete ragione: du conta i file che "vede", invece df da lo spazio libero 
e quei file non vengono quindi davvero cancellati se non al riavvio di 
Apache! Infatti ho verificato che basta dare un restart ad apache per 
ottenere i valori corretti anche in df!