Penggunaan ruang disk tidak sesuai dengan df & du

Saya mencoba untuk membebaskan beberapa ruang disk - jika saya melakukan df -h, saya memiliki sistem file bernama / dev / mapper / vg00-var yang mengatakan 4G, 3,8G digunakan, 205M tersisa.

Itu sesuai dengan direktori saya / var.

Jika saya turun ke / var dan lakukan du -kscxh *, totalnya adalah 2.1G

2.1G + 200M gratis = 2.3G ... Jadi pertanyaan saya adalah, di mana sisa 1.7G?

linux du df

— Codecraft
sumber

Apa yang du -shx /vardikatakan?

— Kyle Smith

Anda juga dapat menghapus file yang memiliki pegangan file terbuka. OS tidak akan melepaskan ruang sampai pegangan ditutup, tetapi Anda tidak akan melihatnya dengan "du". Anda dapat menjalankan "lsof / var | grep dihapus" (atau yang serupa) untuk melihatnya. Ini sebenarnya tidak akan menjadi penemuan mengejutkan, katakanlah, / var / log, jika log diputar tetapi proses logging tidak HUP dengan cara yang benar.

— cjc

Saya telah menghapus beberapa file log yang menjadi gila, seolah-olah mereka tidak berputar, tetapi bagaimanapun, saya punya email satu kata dari teman 'reboot' - mengira dia sedang sarkastik tetapi tampaknya tidak :) I telah menemukan ruang disk saya lagi .... bencana dihindari (untuk saat ini).

— Codecraft

@Codecraft Ya, mem-boot ulang pasti akan menghapus semua pegangan file yang terbuka, meskipun itu seperti memecahkan telur dengan palu.

— cjc

@ cjc selama saya mendapatkan kebaikan yolky ...! Ada saran tentang bagaimana saya bisa menghapus file yang dibuka tanpa memalu telur saya?

— Codecraft

Anda mungkin memiliki beberapa dihapus file log besar, file database atau yang serupa tergeletak di sekitar, menunggu proses memegang file melepaskannya.

Di Linux, penghapusan file hanya memutuskan tautan file. Ini benar-benar dihapus ketika tidak ada lagi pegangan file yang terhubung ke file itu. Jadi, jika Anda memiliki file log 2 GB yang Anda hapus secara manual dengan rm, ruang disk tidak akan dibebaskan sampai Anda me-restart syslog daemon (atau mengirim HUPsinyal ke sana).

Mencoba

lsof -n | grep -i deleted

dan lihat apakah Anda memiliki file zombie yang dihapus masih melayang.

— Janne Pikkarainen
sumber

Saya tidak bisa menjalankan perintah Anda, tetapi apa yang Anda katakan tampaknya tepat - saya telah secara manual membunuh beberapa log-sudah-gila, dan pada akhirnya, reboot menyebabkan ruang disk dihitung ulang dan ditampilkan dengan benar.

— Codecraft

Itu berhasil bagi kami dengan log Apache mengisi direktori / var / log / apache /. Jadi Anda mungkin tidak perlu me-restart seluruh server Anda, atau syslog, hanya layanan yang akan Anda temukan di output dari perintah di atas.

— Yvan

Baru saja memilikinya sendiri. Kami memiliki catalytic tomcat6. Jika tidak tertangkap oleh logrotate, apakah kami menghapusnya ketika mencapai 4Gb dan memperbaiki logrotate. Beberapa minggu kemudian kami bertanya-tanya mengapa 4Gb tidak kembali. Itu lsofperintah menunjukkan kami memiliki banyak file tomcat menunggu keputusan penghapusan. Mulai ulang kucing jantan dan tiba-tiba kita memiliki banyak ruang kembali!

— Nick

Akhirnya jawaban itu berhasil buat saya. PostgreSQL mengalami crash dan meninggalkan koneksi terbuka ke 400GiB (!!!) dari file yang tidak terhubung pada disk 1TiB. Restart Postgres memperbaikinya.

— sudo