Cosa sta consumando il mio spazio su disco?

Sto eseguendo Linux Mint 14 Nadia. La partizione Linux ha 10G. All'avvio del sistema, dusegnala un utilizzo dell'80%. Quindi l'utilizzo cresce lentamente fino a raggiungere il 100% e il sistema diventa inutilizzabile. (Può succedere nell'ordine di giorni o settimane). Dopo il riavvio, l'utilizzo viene ripristinato all'80%.

La cosa più strana di tutte è che dunon mostra alcun cambiamento.

Ecco l'output di questi comandi (sono eliminate le partizioni di unità esterne e Windows):

# --- Just after reboot ---

$ df -h     
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  7.3G  2.0G  80% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M  288K  437M   1% /run/shm
none            100M   12K  100M   1% /run/user

$ sudo du -x   -d1 -h /
186M    /opt
512M    /var
11M /sbin
556K    /root
1.3G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
60K /tmp
9.1M    /bin
4.0K    /srv
7.3G    /            # <-- note this


# --- After some time ---

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  9.1G  199M  98% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M   27M  411M   7% /run/shm
none            100M   28K  100M   1% /run/user

$  sudo du -x   -d1 -h /
186M    /opt
511M    /var
11M /sbin
556K    /root
1.4G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
520K    /tmp
9.1M    /bin
4.0K    /srv
7.3G    /              # <-- note this

(Nota: utilizzo l'ibernazione. Dopo l'ibernazione, l'utilizzo rimane invariato e, dopo il riavvio, viene ripristinato all'80%.)

Come posso tracciare ciò che mangia lo spazio?

Ho letto questa domanda . Sono ancora al buio. Come faccio a sapere quale programma è responsabile di questo comportamento?

Dopo la modifica : trovato. Lo spazio è rivendicato dal log del kernel, che è visto da dmesg. Si riempie perché la mia macchina genera errori al ritmo di 5 al secondo. (È correlato a questo bug .) Lascia che i futuri lettori duabbiano un problema simile - riempiendo lentamente lo spazio su disco senza essere visto da - non dimenticare di provare dmesga cercare la causa.

Esecuzione ripetuta di

sudo du -x   -d1 -h /

(sotto l'albero delle directory) dovrebbe dirti dove viene consumato lo spazio. Ciò probabilmente spiega senza ulteriori indagini quale applicazione lo sta causando.

file invisibili

Se dunon mostra questi file, una delle possibilità sono i file eliminati. Un file (o meglio: il suo nome, cioè la sua voce in una directory) può essere eliminato mentre il file è ancora in uso. Finché esiste un descrittore di file valido che punta a questo file, copre lo spazio sul volume (se non è un file vuoto ...).

cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0

Puoi trovare questi file con find:

find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n     %l\n' 2>/dev/null

Potrebbe essere un singolo file enorme o un mucchio di file più piccoli che causano il tuo problema. Adesso ci sono circa 30 file di questo tipo sul mio sistema (appartenenti solo a cinque processi). ls -lmostra la dimensione di questi file ma non sembra possibile ottenere questo valore da find.

Dopo aver terminato il processo, lo spazio diventa dfnuovamente disponibile per il file system ( ).

Usa qualcosa di simile

lsof -s | grep deleted | sort -k 8

per vedere quali processi mantengono aperti i file eliminati. I campi importanti sono il secondo (PID) e l'ottavo (il terzo dall'ultimo; la dimensione del file).

(Prestare attenzione alle righe duplicate, non contarle due volte. Controllare il PID e il percorso del file (ultimo campo) o il numero dell'inode (dal secondo all'ultimo campo).)

Dopodiché, se trovi un processo che probabilmente è il colpevole, possiamo vedere come risolverlo.

find / -size +10000k -print0 | xargs -0 ls -l -h

Usa questo per trovare ricorsivamente ciò che sta riempiendo più di 10 MB + da /(root) e visualizzalo con molti dettagli con ls -lin xargs. Se scrivi 1000000 (2 zeri extra) puoi ottenere 1 GB + per esempio.

du / -h --max-depth=1 | sort -h

Puoi anche usare du e scavare al suo interno manualmente.

Ogni volta che ciò accade, inizio sempre a concentrarmi su alcune sottodirectory. La struttura FHS a cui aderiscono la maggior parte delle distribuzioni Linux è concepita tenendo presente questo aspetto.

Primo sguardo /var, seguito da /home.

$ sudo du -x -d1 -h /var  | sort -hr`

$ sudo du -x -d1 -h /home | sort -hr`

Puoi restringere la tua attenzione alle sottodirectory all'interno di una di quelle posizioni. Una volta esaurito lo sguardo, di solito mi sposto /roote, infine, le restanti sottodirectory su /.

Se si tratta di una distribuzione basata su Red Hat, la cache che yumutilizza per eseguire gli aggiornamenti potrebbe richiedere molto spazio. Puoi usare questo comando per cancellarlo:

$ yum clean packages

Altre distribuzioni che l'uso aptpuò fare qualcosa di simile, apt-get clean.

Avrei anche eseguito questo comando nella parte superiore della /directory, questa posizione a volte può diventare la fonte per i file di registro vaganti.

$ ls -la /

Prestare particolare attenzione ai file dot! Cose nominate .blah, per esempio.

timeshift stava mangiando il mio disco.

sudo timeshift -delete--all

50 GB recuperati.

Ho quasi la stessa situazione.

Nel mio caso, la ragione era VMware. Uno degli altri VMware sullo stesso computer, ha consumato gli spazi su disco. Ecco perché il mio utilizzo dello spazio su disco è stato del 100%.

Dopo aver eliminato file di grandi dimensioni dal VMware del vicino, funziona correttamente.