eliminazione di file ma lo spazio su disco è ancora pieno

Ho a che fare con la vecchia scatola CentOS 5.6, senza installazione lvm, il mio file system di root / è pieno, ho cancellato molti vecchi file di registro e file dell'applicazione che non mi servono, che erano più di 2-5 GB di dimensioni, tuttavia il mio sistema segnala ancora che il disco è pieno.

[root@tornms1 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             130G  124G     0 100% /
/dev/sdb1             264G  188M  250G   1% /data
/dev/sda1              99M   24M   71M  26% /boot
tmpfs                 2.0G     0  2.0G   0% /dev/shm



[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Qualche idea su cosa dovrei provare a fare dopo? sfortunatamente riavviare il box non è un'opzione in questo momento.

Qui potrebbero succedere due cose.

Innanzitutto , il tuo filesystem ha riservato uno spazio che rootpuò solo scrivere, in modo che il processo di sistema critico non cada quando gli utenti normali esauriscono lo spazio su disco. Ecco perché vedi 124G di 130G usati, ma zero disponibili. Forse i file che hai eliminato hanno portato l'utilizzo a questo punto, ma non al di sotto della soglia per gli utenti normali.

Se questa è la tua situazione e sei disperato, potresti essere in grado di modificare la quantità di spazio riservato per root. Per ridurlo all'1% (il valore predefinito è 5%), il comando sarebbe

# tune2fs -m 1 /dev/sda3

In secondo luogo , il sistema operativo non rilascerà spazio su disco per i file eliminati che sono ancora aperti. Se hai eliminato (diciamo) uno dei file di registro di Apache, dovrai riavviare Apache per liberare spazio.

Se si elimina un file utilizzato da un processo, non è più possibile visualizzarlo ls. Il processo continua a scrivere su quel file fino a quando non si interrompe il processo.

Per visualizzare quei file eliminati, esegui semplicemente lsof|grep delete

Altri 2 modi per ottenere il disco sono un problema completo :

1) nascosto sotto un punto di montaggio: Linux mostrerà un disco completo con i file "nascosti" sotto un punto di montaggio. Se hai dei dati scritti sull'unità e monti un altro filesystem su di esso, Linux nota correttamente l'utilizzo del disco anche se non puoi vedere i file sotto il punto di mount. Se hai montaggi nfs, prova a smontarli e cerca di vedere se qualcosa è stato accidentalmente scritto in quelle directory prima del montaggio.

2) file corrotti: lo vedo occasionalmente su Windows per il trasferimento di file Linux tramite SMB. Un file non riesce a chiudere il descrittore di file e ti ritrovi con un file di cestino da 4 GB.

Questo può essere più noioso da risolvere, perché è necessario trovare la sottodirectory in cui si trova il file, ma è facile da risolvere perché il file stesso è facilmente rimovibile. Uso il ducomando e faccio un elenco dei sottodirectory root per scoprire dove viene utilizzato lo spazio file.

cd /
du -sh ./* 

Il numero di directory di livello superiore è generalmente limitato, quindi ho impostato il flag di lettura umana-h per vedere quale sottodirectory è il maiale dello spazio.

Quindi esegui il cd nel figlio problematico e ripeti il ​​processo per tutti gli elementi in esso contenuti. Per facilitare l'individuazione degli oggetti di grandi dimensioni, cambiamo leggermente il du e lo accoppiamo con una specie.

cd /<suspiciously large dir>
du -s ./* | sort -n

che produce un output dal più piccolo al più grande per dimensione byte per tutti i file e le directory

4          ./bin 
462220     ./Documents
578899     ./Downloads
5788998769 ./Grocery List

Una volta individuato il file di grandi dimensioni, in genere è possibile eliminarlo.

Puoi scoprire quali file sono aperti con lsof. Può produrre un sacco di output, quindi ho limitato l'esempio di seguito alle righe che terminano con log:

# lsof | grep log$
rsyslogd   2109     syslog    0u     unix 0xffff88022fa230c0      0t0       8894      /dev/log
rsyslogd   2109     syslog    1w      REG              252,6    62393         26 /var/log/syslog
rsyslogd   2109     syslog    2w      REG              252,6   113725        122 /var/log/auth.log
rsyslogd   2109     syslog    3u     unix 0xffff88022fa23740      0t0       8921 /var/spool/postfix/dev/log
rsyslogd   2109     syslog    5w      REG              252,6    65624        106 /var/log/mail.log
/usr/sbin  2129       root    2w      REG              252,6    93602         38 /var/log/munin/munin-node.log
/usr/sbin  2129       root    4w      REG              252,6    93602         38 /var/log/munin/munin-node.log
...

Se alcuni file vengono eliminati ma ancora utilizzati da alcuni processi, lo spazio non verrà rilasciato. In questo caso, riavviare un processo che utilizza il file o annullare il file. È sempre buona norma annullare l'archiviazione di tali file invece di eliminarli. Per trovare i file eliminati ma sono ancora in uso da qualche processo

#lsof +L1

fornirà ID processo e descrittore di file. Annullare il file cancellato dal descrittore di file

#echo "" > /proc/$pid/fd/$fd 

Digita il comando

#lsof +L1

Che mostrerà l'elenco dei file che contengono memoria con la citazione eliminata.

Nota il pid (ID processo) del file

Uccidi il processo

#kill <pid>

La memoria verrà rilasciata dal processo

Controllalo a comando

#df -h

Oltre a ciò che è stato spiegato, il problema potrebbe essere che esiste un altro punto di montaggio della directory dei file eliminati su un altro dispositivo disco collegato sullo stesso server. Controllare i supporti correnti e le voci fstab.

Problema reale osservato in natura:

Assicurati di eliminare i file effettivi e non i collegamenti simbolici ai file. Questo può essere il caso in particolare dei file di registro.