File system full

Salve a tutti.
Problema stupido, ma comportamento anomalo.

La cosa mi è capitata un paio di volte, ma su dei server di
sviluppo/test/prova e non ho dato troppa attenzione, ma oggi sono dovuto
intervenire su un server di produzione.
Insomma mi chiamano per un server che non va e dopo una veloce verifica
vedo che il disco è pieno. Il disco è in UFS.
Spazio libero -24k

Faccio un analisi e decido di cominciare a liberare lo spazio
cancellando alcuni log di grosse dimensioni e dei backup.
Elimino una decina di backup delle basi di dati vecchi di 5, 6 e 7
giorni (un totale di ~4G), verifico lo spazio disponibile e continua ad
essere -24k.
Studiando che fare verifico i messaggi di posta elettronica
(/var/spool/mail/root) vedo che ce ne sono alcune migliaia, cancello i
messaggi, viene eliminato il file e lo spazio disponibile aumenta a 9K
(finalmente positivo). Faccio lo stesso con i messaggi di posta degli
utenti root delle varie jail e lo spazio disponibile aumenta, di poco.
Continuo cancellando alcuni file di log (~300M), ma lo spazio
disponibile non cambia. Cancellando invece file di log più piccoli (<1M)
lo spazio disponibile aumenta.

Mi sono accorto che eliminando file piccoli effettivamente si libera
spazio. Eliminando file grossi invece no.
Lancio un fsck_ufs ed effettivamente mi dice che ci sono errori
pendenti. Ovviamente con il disco montato potevo fare poco.
Riavvio con un CD, eseguo il check del disco (riporto l'outpun in
fondo), verifico lo spazio disponibile e trovo 11G liberi. Ben problema
risolto.

Domanda, perché cancellando file di grosse dimensioni lo spazio non si
libera? Esiste la possibilità con macchina accesa di risolvere questo
malfunzionamento, cioè di far risultare l'effettivo spazio libero?
(tengo a precisare che i file cancellati non erano aperti da nessun
processo)

Grazie per eventuali dritte.

Check del disco:
root@rescue-bsd:~ # fsck_ufs /dev/mirror/gm0s1a
** /dev/mirror/gm0s1a

USE JOURNAL? [yn] y

** SU+J Recovering /dev/mirror/gm0s1a
** Reading 33554432 byte journal from inode 4.

RECOVER? [yn] y

** Building recovery table.
** Resolving unreferenced inode list.
** Processing journal entries.

WRITE CHANGES? [yn] y

** 14 journal records in 1536 bytes for 29.17% utilization
** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags.

***** FILE SYSTEM MARKED CLEAN *****

-- 
Cordiali saluti
Sossi Andrej
-------------------------
DOTCOM Information technology

Via Machiavelli, 28
34132 - Trieste (TS)
Italy

tel: +39 040 9828090
fax: +39 040 0641954
E-mail: [email protected]
----------------------------

Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si precisa che
le informazioni contenute in questo messaggio sono riservate e ad uso
esclusivo del destinatario. Qualora il messaggio in parola Le fosse
pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non
inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie

This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may
contain confidential and/or privileged information. If you are not the
addressee or authorized to receive this for the addressee, you must not
use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please
advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.

_______________________________________________
Esperti mailing list
[email protected]
http://mailman.gufi.org/mailman/listinfo/esperti