Apa yang memakan ruang disk saya?

Saya menjalankan Linux Mint 14 Nadia. Partisi Linux memiliki 10G. Saat sistem dimulai, dumelaporkan penggunaan 80%. Kemudian penggunaannya perlahan-lahan tumbuh hingga mencapai 100% dan sistem menjadi tidak dapat digunakan. (Itu bisa terjadi berdasarkan urutan hari atau minggu). Setelah reboot, pengaturan ulang ke 80%.

Yang paling aneh dari semua itu adalah dutidak ada perubahan.

Berikut ini adalah output dari perintah tersebut (partisi drive Windows dan eksternal dihilangkan):

# --- 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

(Catatan: Saya menggunakan hibernasi. Setelah hibernasi, penggunaannya tetap sama, dan setelah reboot, reset ke 80%.)

Bagaimana cara melacak apa yang memakan ruang?

Saya sudah membaca pertanyaan ini . Saya masih dalam kegelapan. Bagaimana saya mengetahui program mana yang bertanggung jawab atas perilaku ini?

Setelah diedit : ditemukan. Ruang diklaim oleh log kernel, yang dilihat oleh dmesg. Mengisi karena mesin saya menghasilkan kesalahan pada tingkat 5 per detik. (Ini terkait dengan bug ini .) Biarkan pembaca yang akan datang dengan masalah yang sama - mengisi ruang disk secara perlahan du- dengan jangan lupa untuk mencoba dmesgmencari penyebabnya.

Eksekusi berulang

sudo du -x   -d1 -h /

(turun pohon direktori) harus memberi tahu Anda di mana ruang dikonsumsi. Itu mungkin menjelaskan tanpa penyelidikan lebih lanjut aplikasi mana yang menyebabkan itu.

file tidak terlihat

Jika dutidak menampilkan file-file ini maka salah satu kemungkinan adalah file yang dihapus. File (atau lebih tepatnya: namanya yaitu entri dalam direktori) dapat dihapus saat file masih digunakan. Selama ada deskriptor file yang valid menunjuk pada file ini mencakup ruang pada volume (jika bukan file kosong ...).

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

Anda dapat menemukan file-file ini dengan 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

Ini mungkin satu file besar tunggal atau banyak file kecil yang menyebabkan masalah Anda. Ada sekitar 30 file seperti itu di sistem saya sekarang (hanya milik lima proses). ls -lmenunjukkan ukuran file-file ini tetapi tampaknya tidak mungkin untuk mendapatkan nilai ini dari find.

Setelah membunuh proses, ruang menjadi tersedia untuk sistem file ( df) lagi.

Gunakan sesuatu seperti

lsof -s | grep deleted | sort -k 8

untuk melihat proses mana yang membuat file yang dihapus tetap terbuka. Kolom penting adalah yang kedua (PID), dan yang kedelapan (ketiga dari terakhir; ukuran file).

(Perhatikan baris duplikat, jangan hitung dua kali. Periksa PID dan path file (bidang terakhir) atau nomor inode (bidang kedua ke terakhir).)

Setelah itu, jika Anda menemukan proses yang kemungkinan besar pelakunya, kita bisa melihat cara memperbaikinya.

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

Gunakan ini untuk menemukan rekursif apa yang mengisi lebih dari 10MB + dari /(root), dan menampilkannya dengan rincian banyak dengan ls -ldi xargs. Jika Anda menulis 1000000 (2 angka nol tambahan) Anda bisa mendapatkan 1GB + misalnya.

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

Anda juga dapat menggunakan du, dan cukup gali secara manual.

Setiap kali ini terjadi, saya selalu memulai fokus saya di sub-direktori tertentu. Struktur FHS yang dipatuhi oleh kebanyakan distro Linux dipikirkan dengan seksama.

Pertama melihat /var, diikuti oleh /home.

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

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

Anda dapat mempersempit fokus Anda ke sub-direktori di dalam salah satu lokasi itu juga. Setelah Anda lelah mencari di sana, saya biasanya pindah ke /root, dan terakhir sub-direktori yang tersisa di /.

Jika itu adalah distro berbasis Red Hat, cache yang yumdigunakan untuk melakukan pembaruan mungkin menghabiskan banyak ruang. Anda dapat menggunakan perintah ini untuk menghapusnya:

$ yum clean packages

Distro lain yang menggunakan aptdapat melakukan hal serupa apt-get clean,.

Saya juga menjalankan perintah ini di bagian atas /direktori Anda , lokasi ini kadang-kadang dapat menjadi sumber untuk file log liar.

$ ls -la /

Berikan perhatian khusus pada file dot! Hal-hal yang dinamai .blah, misalnya.

timeshift sedang memakan disk saya.

sudo timeshift -delete--all

Dipulihkan 50GB.

Saya punya situasi yang hampir sama.

Dalam kasus saya, alasannya adalah VMware. Salah satu VMware lain di mesin yang sama, ia mengkonsumsi ruang disk. Itu sebabnya penggunaan ruang disk saya adalah 100%.

Setelah menghapus file besar dari VMware tetangga, itu berfungsi dengan benar.