Disco pieno, du dice diverso. Come indagare ulteriormente?

Ho un disco SCSI in un server (hardware Raid 1), 32G, ext3 filesytem. dfmi dice che il disco è pieno al 100%. Se cancello 1G questo è mostrato correttamente.

Tuttavia, se corro a, du -h -x /allora dumi dice che vengono utilizzati solo 12G (lo uso a -xcausa di alcuni supporti Samba).

Quindi la mia domanda non riguarda le sottili differenze tra i comandi du e df ma su come posso scoprire cosa causa questa enorme differenza?

Ho riavviato la macchina per un fsck che è andato senza errori. Dovrei correre badblocks? lsofnon mi mostra alcun file eliminato aperto, lost+foundè vuoto e non vi è alcuna chiara istruzione warn / err / fail nel file dei messaggi.

Sentiti libero di chiedere ulteriori dettagli sulla configurazione.

Controlla i file che si trovano sotto i punti di montaggio. Spesso se montate una directory (diciamo un sambafs) su un filesystem che aveva già un file o directory sotto di essa, perdete la capacità di vedere quei file, ma stanno ancora consumando spazio sul disco sottostante. Ho avuto copie dei file mentre ero in modalità utente singolo, scarica i file in directory che non riuscivo a vedere se non nella modalità utente singola (a causa del montaggio di altri sistemi di directory su di essi).

Mi sono appena imbattuto in questa pagina quando ho cercato di rintracciare un problema su un server locale.

Nel mio caso il df -he du -shnon corrispondeva a circa il 50% della dimensione del disco rigido.

Ciò è stato causato da apache (httpd) che mantiene in memoria file di registro di grandi dimensioni che sono stati eliminati dal disco.

Questo è stato rintracciato correndo lsof | grep "/var" | grep deleteddov'era /varla partizione di cui avevo bisogno per ripulire.

L'output ha mostrato linee come questa:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

La situazione è stata quindi risolta riavviando apache ( service httpd restart) e liberato 2 GB di spazio su disco, consentendo la cancellazione dei blocchi sui file eliminati.

Concordo con la risposta di OldTroll come la causa più probabile per il tuo spazio "mancante".

Su Linux puoi facilmente rimontare l'intera partizione di root (o qualsiasi altra partizione per quella materia) in un altro posto nel tuo filesystem dire / mnt per esempio, basta emettere un

mount -o bind / /mnt

allora puoi fare un

du -h /mnt

e vedi cosa consuma il tuo spazio.

Ps: scusami per aver aggiunto una nuova risposta e non un commento, ma avevo bisogno di un po 'di formattazione per questo post per essere leggibile.

Vedi cosa df -idice. È possibile che tu abbia esaurito gli inode, il che potrebbe accadere se ci fosse un gran numero di piccoli file in quel filesystem, che utilizza tutti gli inode disponibili senza consumare tutto lo spazio disponibile.

Nel mio caso questo ha avuto a che fare con file eliminati di grandi dimensioni. È stato abbastanza doloroso da risolvere prima di trovare questa pagina, che mi ha messo sulla strada giusta.

Ho finalmente risolto il problema utilizzando lsof | grep deleted, che mi ha mostrato quale programma conteneva due file di registro molto grandi (per un totale di 5 GB della mia partizione di root disponibile da 8 GB).

I file aperti da un programma in realtà non vanno via (smettono di consumare spazio su disco) quando li elimini, vanno via quando il programma li chiude. Un programma potrebbe avere un enorme file temporaneo che tu (e du) non potete vedere. Se è un programma zombi, potrebbe essere necessario riavviare per cancellare quei file.

Prova questo per vedere se un processo dead / hung è bloccato mentre stai ancora scrivendo sul disco: lsof | grep "/ mnt"

Quindi prova a eliminare tutti i PID bloccati (in particolare cerca le righe che terminano con "(eliminato"))

Questo è il metodo più semplice che ho trovato fino ad oggi per trovare file di grandi dimensioni!

Ecco un esempio se il tuo root mount è pieno / (mount / root) Esempio:

cd / (quindi sei nel root)

ls | xargs du -hs

Esempio di output:

 9,4 M bin
 63M di avvio
 Cgroup da 4,0 K.
 680K dev
 31 M ecc
 6.3G a casa
 313M lib
 32M lib64
 16K persi + trovati
 61G media
 4.0K mnt
 113M opt
 du: impossibile accedere a `proc / 6102 / task / 6102 / fd / 4 ': nessun file o directory
 0 proc
 19M di root
 840K di corsa
 19M sbin
 4.0K selinux
 4.0K srv
 Negozio 25G
 26M tmp

allora noteresti che il negozio è grande e fai un cd / store

e corri di nuovo

ls | xargs du -hs

Esempio di output: 
 109M di backup
 358M fnb
 4.0G iso
 8.0K ks
 16K persi + trovati
 Radice 47M
 Script 11M
 79M tmp
 21G vms

in questo caso la directory vms è lo spazio hog.

Per me, dovevo correre sudo duperché c'erano molti file docker in base ai /var/lib/dockerquali un utente non sudo non aveva il permesso di leggere.

Un'altra possibilità da considerare: se si utilizza la finestra mobile, si è quasi certi di riscontrare una grande discrepanza e si esegue df / du all'interno di un contenitore che utilizza montaggi di volume. Nel caso di una directory montata su un volume sull'host docker, df riporterà i totali df dell'HOST. Questo è ovvio se ci pensi, ma quando ricevi un rapporto su un "contenitore in fuga che riempie il disco!", Assicurati di verificare il consumo dello spazio file del contenitore con qualcosa del genere du -hs <dir>.

Quindi ho avuto questo problema anche in Centos 7 e ho trovato una soluzione dopo aver provato un sacco di cose come bleachbit e cleaning / usr e / var anche se hanno mostrato solo circa 7G ciascuno. Stava ancora mostrando 50G di 50G usati nella partizione root ma mostrava solo 9G di utilizzo dei file. Ha eseguito un cd di Ubuntu live e ha smontato la partizione 50G offensiva, ha aperto il terminale ed eseguito xfs_check e xfs_repair sulla partizione. Ho quindi rimontato la partizione e la mia directory lost + found si è espansa a 40G. Ordinato il perso + trovato per dimensione e trovato un file di registro di testo 38G per Steam che alla fine ha appena ripetuto un errore mp3. Rimosso il file di grandi dimensioni e ora ho spazio e l'utilizzo dei miei dischi concorda con la dimensione della mia partizione di root. Vorrei ancora sapere come fare in modo che il registro vapore non cresca di nuovo così grande.

se il disco montato è una cartella condivisa su un computer Windows, allora sembra che df mostrerà le dimensioni e l'uso del disco dell'intero disco di Windows, ma du mostrerà solo la parte del disco a cui hai accesso. (ed è montato). quindi in questo caso il problema deve essere risolto sul computer Windows.

Una cosa simile ci è successa in produzione, l'utilizzo del disco è andato al 98%. Ha fatto la seguente indagine:

a) df -iper verificare l'utilizzo dell'inode, l'utilizzo dell'inode era del 6%, quindi non file molto più piccoli

b) Montaggio roote controllo di file nascosti. Impossibile archiviare file aggiuntivi . dui risultati erano gli stessi di prima del mount.

c) Infine, nginxregistri controllati . È stato configurato per scrivere su disco ma uno sviluppatore ha eliminato direttamente il file di registro causando la nginxconservazione di tutti i registri in memoria. Poiché il file è /var/log/nginx/access.logstato eliminato dal disco utilizzando rmnon era visibile utilizzando duma il file era accessibile nginxe quindi era ancora aperto

Ho avuto lo stesso problema menzionato in questo argomento, ma in un VPS. Quindi ho testato tutto ciò che è descritto in questo argomento, ma senza successo. La soluzione è stata un contatto per il supporto con il nostro provider VPS che ha eseguito un ricalcolo delle quote e ha corretto la differenza di spazio di df -he du-sh /.

Ho riscontrato questo problema su una scatola di FreeBSD oggi. Il problema era che si trattava di un artefatto di vi(non vim, non sono sicuro se vimavrebbe creato questo problema). Il file stava consumando spazio ma non era stato completamente scritto su disco.

Puoi verificarlo con:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Questo esamina tutti i file e gli ordinamenti aperti (numericamente tramite -n) dall'ottava colonna (chiave, -k8), mostrando gli ultimi dieci elementi.

Nel mio caso, la voce (più grande) finale sembrava così:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Ciò significava che il processo (PID) 12345 consumava 1,46 G (l'ottava colonna divisa per 1024³) di disco nonostante la mancanza di notarlo du. viè orribile a visualizzare file di dimensioni estremamente grandi; anche 100 MB sono grandi per questo. 1,5 G (o per quanto grande fosse quel file in realtà) è ridicolo.

La soluzione era sudo kill -HUP 12345(se non avesse funzionato, l'avrei fatto sudo kill 12345e se anche quello non avesse funzionato , il temuto kill -9sarebbe entrato in gioco).

Evita gli editor di testo su file di grandi dimensioni. Soluzioni alternative di esempio per una rapida scrematura:

Supponendo lunghezze di linea ragionevoli:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Supponendo che le righe siano irragionevolmente grandi:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Questi usano vim -Ral posto di viewperché vimè quasi sempre meglio ... quando è installato. Sentiti libero di convogliarli viewo vi -Rinvece.

Se stai aprendo un file così grande per modificarlo effettivamente, considera sedo awko qualche altro approccio programmatico.

controlla se sul tuo server è installato ossec agent. Oppure alcuni processi utilizzano i file di registro eliminati. Nel mio tempo fa era ossec agente.

controlla il / lost + found, avevo un sistema (centos 7) e alcuni file nel / lost + found hanno mangiato tutto lo spazio.