Disk penuh, du mengatakan berbeda. Bagaimana cara menyelidiki lebih lanjut?

Saya memiliki disk SCSI di server (hardware Raid 1), 32G, ext3 filesytem. dfmemberitahu saya bahwa disk tersebut 100% penuh. Jika saya menghapus 1G ini ditampilkan dengan benar.

Namun, jika saya menjalankan du -h -x /maka duberi tahu saya bahwa hanya 12G yang digunakan (saya gunakan -xkarena beberapa samba mount).

Jadi pertanyaan saya bukan tentang perbedaan halus antara perintah du dan df tetapi tentang bagaimana saya bisa mengetahui apa yang menyebabkan perbedaan besar ini?

Saya reboot mesin untuk fsck yang pergi tanpa kesalahan. Haruskah saya berlari badblocks? lsofmenunjukkan kepada saya tidak ada file yang dihapus terbuka, lost+foundkosong dan tidak ada pernyataan peringatan / kesalahan / kegagalan yang jelas dalam file pesan.

Jangan ragu untuk meminta perincian lebih lanjut tentang pengaturan.

Periksa file pada yang terletak di bawah titik pemasangan. Seringkali jika Anda memasang direktori (katakanlah sambafs) ke sistem file yang sudah memiliki file atau direktori di bawahnya, Anda kehilangan kemampuan untuk melihat file-file itu, tetapi mereka masih menghabiskan ruang pada disk yang mendasarinya. Saya sudah memiliki salinan file saat dalam mode pengguna tunggal membuang file ke direktori yang tidak bisa saya lihat kecuali dalam usermode tunggal (karena sistem direktori lain sedang dipasang di atas mereka).

Baru saja menemukan halaman ini ketika mencoba melacak masalah di server lokal.

Dalam kasus saya df -hdan du -shtidak cocok dengan sekitar 50% dari ukuran hard disk.

Ini disebabkan oleh apache (httpd) menyimpan file-file log besar dalam memori yang telah dihapus dari disk.

Ini dilacak dengan menjalankan di lsof | grep "/var" | grep deletedmana /varpartisi saya perlu dibersihkan.

Outputnya menunjukkan baris seperti ini:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Situasi kemudian diselesaikan dengan me-restart apache ( service httpd restart), dan membersihkan ruang disk 2gb, dengan membiarkan kunci pada file yang dihapus dihapus.

Saya setuju dengan jawaban OldTroll sebagai kemungkinan penyebab ruang "hilang" Anda.

Di Linux Anda dapat dengan mudah me-remount seluruh partisi root (atau partisi lain untuk hal ini) ke tempat lain di sistem file Anda katakan / mnt misalnya, cukup mengeluarkan

mount -o bind / /mnt

maka kamu bisa melakukan a

du -h /mnt

dan lihat apa yang menghabiskan ruang Anda.

Ps: maaf karena menambahkan jawaban baru dan bukan komentar tetapi saya perlu beberapa format agar posting ini dapat dibaca.

Lihat apa yang df -idikatakan. Bisa jadi Anda kehabisan inode, yang mungkin terjadi jika ada sejumlah besar file kecil dalam sistem file itu, yang menggunakan semua inode yang tersedia tanpa menghabiskan semua ruang yang tersedia.

Dalam kasus saya ini ada hubungannya dengan file-file besar yang dihapus. Cukup menyakitkan untuk dipecahkan sebelum saya menemukan halaman ini, yang membuat saya berada di jalur yang benar.

Saya akhirnya memecahkan masalah dengan menggunakan lsof | grep deleted, yang menunjukkan saya program mana yang memegang dua file log yang sangat besar (total 5GB dari partisi root 8GB saya yang tersedia).

File yang dibuka oleh suatu program tidak benar-benar pergi (berhenti memakan ruang disk) ketika Anda menghapusnya, mereka akan pergi ketika program menutupnya. Suatu program mungkin memiliki file sementara besar yang tidak dapat Anda (dan du) lihat. Jika ini adalah program zombie, Anda mungkin perlu me-reboot untuk menghapus file-file itu.

Coba ini untuk melihat apakah proses mati / macet terkunci ketika masih menulis ke disk: lsof | grep "/ mnt"

Kemudian coba matikan semua PID yang macet (terutama cari baris yang diakhiri dengan "(dihapus"))

Ini adalah metode termudah yang saya temukan hingga saat ini untuk menemukan file besar!

Ini adalah contoh jika mount root Anda penuh / (mount / root) Contoh:

cd / (jadi Anda sudah di root)

ls | xargs du -hs

Contoh Output:

 Bin 9,4M
 63M boot
 4.0K cgroup
 680K dev
 31 jt dll
 6.3G rumah
 313 juta lib
 Libre 32M
 16K hilang + ditemukan
 61G media
 4.0rb mnt
 113M opt
 du: tidak dapat mengakses `proc / 6102 / task / 6102 / fd / 4 ': Tidak ada file atau direktori tersebut
 0 proc
 Root 19M
 Lari 840K
 19M sbin
 4.0K selinux
 4.0K srv
 Toko 25G
 26M tmp

maka Anda akan melihat bahwa toko besar melakukan cd / store

dan jalankan lagi

ls | xargs du -hs

Contoh output: 
 Cadangan 109 juta
 358M fnb
 4.0G iso
 8.0K ks
 16K hilang + ditemukan
 47 m root
 11 juta skrip
 79M tmp
 21G vms

dalam hal ini direktori vms adalah space hog.

Bagi saya, saya perlu menjalankan sudo dukarena ada sejumlah besar file buruh pelabuhan di bawah /var/lib/dockerbahwa pengguna non-sudo tidak memiliki izin untuk membaca.

Satu lagi kemungkinan untuk dipertimbangkan - Anda hampir dijamin untuk melihat perbedaan besar jika Anda menggunakan buruh pelabuhan, dan Anda menjalankan df / du di dalam sebuah wadah yang menggunakan volume mount. Dalam kasus direktori yang dipasang ke volume pada host buruh pelabuhan, df akan melaporkan total dOST HOST. Ini jelas jika Anda memikirkannya, tetapi ketika Anda mendapatkan laporan "wadah pelarian yang mengisi disk!", Pastikan Anda memverifikasi konsumsi ruang file kontainer dengan sesuatu seperti du -hs <dir>.

Jadi saya punya masalah ini di Centos 7 juga dan menemukan solusi setelah mencoba banyak hal seperti bleachbit dan pembersihan / usr dan / var meskipun mereka hanya menunjukkan sekitar 7G masing-masing. Masih menampilkan 50G dari 50G yang digunakan di partisi root tetapi hanya menunjukkan 9G penggunaan file. Jalankan cd ubuntu langsung dan lepaskan partisi 50G yang menyinggung, buka terminal dan jalankan xfs_check dan xfs_repair pada partisi tersebut. Saya kemudian me-remount partisi dan direktori yang hilang + saya temukan telah berkembang menjadi 40G. Mengurutkan + yang hilang ditemukan berdasarkan ukuran dan menemukan file log teks 38G untuk steam yang akhirnya hanya mengulangi kesalahan mp3. Menghapus file besar dan sekarang memiliki ruang dan penggunaan disk saya setuju dengan ukuran partisi root saya. Saya masih ingin tahu bagaimana cara mendapatkan steam log agar tidak bertambah besar lagi.

jika disk yang dipasang adalah folder bersama pada mesin windows, maka nampaknya df akan menunjukkan ukuran dan penggunaan disk dari seluruh disk windows, tetapi du hanya akan menampilkan bagian dari disk yang Anda akses juga. (dan sudah terpasang). jadi dalam hal ini masalahnya harus diperbaiki pada mesin windows.

Hal serupa terjadi pada kami dalam produksi, penggunaan disk menjadi 98%. Lakukan penyelidikan berikut:

a) df -iuntuk memeriksa penggunaan inode, penggunaan inode adalah 6% sehingga tidak banyak file yang lebih kecil

b) Memasang rootdan memeriksa file tersembunyi. Tidak dapat mengajukan file tambahan apa pun . duhasilnya sama seperti sebelum mount.

c) Akhirnya, nginxlog yang diperiksa . Itu dikonfigurasikan untuk menulis ke disk tetapi pengembang menghapus file log secara langsung menyebabkan nginxsemua log tetap dalam memori. Karena file /var/log/nginx/access.logdihapus dari disk menggunakan rmitu tidak terlihat menggunakan dutetapi file itu diakses oleh nginxdan karenanya itu masih terbuka

Saya memiliki masalah yang sama yang disebutkan dalam topik ini, tetapi dalam satu VPS. Jadi saya telah menguji semua yang dijelaskan dalam topik ini tetapi tidak berhasil. Solusinya adalah kontak untuk dukungan dengan penyedia VPS kami yang melakukan perhitungan kuota dan mengoreksi perbedaan ruang df -hdan du-sh /.

Saya mengalami masalah ini pada kotak FreeBSD hari ini. Masalahnya adalah bahwa itu adalah artefak vi(tidak vim, tidak yakin apakah vimakan membuat masalah ini). File itu memakan ruang tetapi tidak sepenuhnya ditulis ke disk.

Anda dapat memeriksanya dengan:

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

Ini terlihat pada semua file yang terbuka dan mengurutkan (melalui angka -n) oleh kolom ke-8 (kunci, -k8), menunjukkan sepuluh item terakhir.

Dalam kasus saya, entri final (terbesar) terlihat seperti ini:

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

Ini berarti proses (PID) 12345 mengkonsumsi 1,46G (kolom kedelapan dibagi 1024³) disk meskipun kurangnya dumemperhatikan itu. vimengerikan dalam melihat file yang sangat besar; bahkan 100MB besar untuk itu. 1.5G (atau seberapa besar sebenarnya file itu) konyol.

Solusinya adalah sudo kill -HUP 12345(jika itu tidak berhasil, saya akan sudo kill 12345dan jika itu juga gagal, yang ditakuti kill -9akan ikut bermain).

Hindari editor teks pada file besar. Contoh solusi untuk skimming cepat:

Dengan asumsi panjang garis yang masuk akal:

• { 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 -

Dengan asumsi garis yang terlalu besar:

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

Ini digunakan vim -Rsebagai ganti viewkarena vimhampir selalu lebih baik ... ketika itu diinstal. Jangan ragu untuk memasangnya ke viewatau vi -Rsebagai gantinya.

Jika Anda membuka file besar untuk benar-benar mengeditnya, pertimbangkan sedatau awkatau pendekatan program lainnya.

periksa apakah server Anda sudah menginstal agen ossec. Atau beberapa proses menggunakan file log yang dihapus. Di masa lalu saya adalah agen ossec.

periksa / hilang + ditemukan, saya punya sistem (centos 7) dan beberapa file di / hilang + ditemukan memakan semua ruang.