Disk Space Problems

Pesan No space left on device jarang muncul di tempat yang jujur. Yang terlihat justru gejala pinggirannya: login tiba-tiba gagal, apt mogok di tengah unduhan, database berhenti menulis, atau desktop menolak menyimpan pengaturan. Semuanya bermuara pada satu keadaan yang bisa dibuktikan dalam hitungan detik: ruang disk atau inode yang habis. Chapter ini menyusun perburuan klasiknya — petakan dengan df, bongkar dengan du, temukan tersangka terbesar — lalu membersihkan dengan alat resminya, bukan dengan hapus-besar-besaran.

Dua Jenis Penuh: Blok dan Inode #

Langkah pertama selalu df -h, dan keluarannya harus dibaca sampai kolom terakhir. Berikut contoh tampilan mesin yang bermasalah:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   38G     0 100% /
/dev/sda1       472M   58M  390M  13% /boot

Baris /dev/sda2 memangkas semua dugaan: filesystem root penuh 100%, sedangkan /boot longgar — masalah ada di partisi root, bukan di sistemnya. Pemeriksaan kedua sering dilupakan: df -i menghitung inode, yaitu jumlah entri file yang sanggup ditampung filesystem. Disk yang masih longgar tetapi IFree-nya nol biasanya dipenuhi jutaan file kecil — khas direktori cache sesi dan folder email per-user. Dua angka ini menentukan arah perburuan; pembacaan lengkap keduanya sudah kita latih di Chapter Disk Monitoring .

Kasus 1: Membongkar Hierarki dengan du #

Mengetahui root penuh belum menyebut pelakunya, karena filesystem root menampung ribuan direktori. Pola bongkarnya berlapis: du --max-depth=1 dari sebuah direktori, urutkan yang terbesar, masuk ke yang terbesar itu, ulangi. Karena du pada sistem sungguhan membutuhkan hak baca luas, kita latih polanya pada fixture yang meniru isi /var mesin korban dengan ukuran yang pasti:

mkdir -p var-sim/log var-sim/cache/apt/archives var-sim/jurnal
dd if=/dev/zero of=var-sim/log/app.log bs=1024 count=400 status=none
dd if=/dev/zero of=var-sim/log/app.log.1 bs=1024 count=250 status=none
dd if=/dev/zero of=var-sim/cache/apt/archives/nginx.deb bs=1024 count=150 status=none
dd if=/dev/zero of=var-sim/jurnal/systemd bs=1024 count=600 status=none
du -sh var-sim
du -h --max-depth=1 var-sim | sort -rh

Output yang Dihasilkan:

1.4M	var-sim
1.4M	var-sim
656K	var-sim/log
604K	var-sim/jurnal
164K	var-sim/cache

Dua baris teratas adalah undangan turun satu tingkat: var-sim/log (656 KB) dan var-sim/jurnal (604 KB) — keduanya jauh di atas cache. Bedah perintahnya:

1. Empat dd: membuat file berukuran pasti dalam kelipatan 1 KB; if=/dev/zero adalah sumber nol tanpa batas, status=none meredam laporan statistiknya.
2. du -sh var-sim: ringkasan satu baris untuk total keseluruhan — angka pembanding sebelum dan sesudah pembersihan.
3. du -h --max-depth=1 var-sim: membatasi kedalaman satu tingkat agar keluaran tidak dibanjiri seluruh pohon; sort -rh mengurutkan angka human-readable dari terbesar.
4. Trik -x di mesin sungguhan: menambahkan -x membuat du tidak menyeberang ke filesystem lain — penting saat membongkar / agar partisi yang di-mount tidak ikut terhitung.

Setelah tersangka level direktori ditemukan, giliran file per satuannya:

mkdir -p var-sim/log var-sim/cache/apt/archives var-sim/jurnal
dd if=/dev/zero of=var-sim/log/app.log bs=1024 count=400 status=none
dd if=/dev/zero of=var-sim/log/app.log.1 bs=1024 count=250 status=none
dd if=/dev/zero of=var-sim/cache/apt/archives/nginx.deb bs=1024 count=150 status=none
dd if=/dev/zero of=var-sim/jurnal/systemd bs=1024 count=600 status=none
find var-sim -type f -printf '%s %p\n' | sort -rn | head -3

Output yang Dihasilkan:

614400 var-sim/jurnal/systemd
409600 var-sim/log/app.log
256000 var-sim/log/app.log.1

Dua file log aplikasi menyumbang 650 KB dari dalam var-sim/log — dan itu satu peringatan tentang rotasi log yang lupa berjalan. Rantai find | sort | head adalah versi cepatnya: find -printf '%s %p\n' mencetak ukuran byte lalu path tiap file, sort -rn mengurutkan numerik descending, dan head -3 memotong tiga teratas. Pada mesin nyata, tambahkan -xdev pada find agar pencarian tidak menyeberang filesystem.

Tempat Sampah Klasik dan Pembersih Resminya #

Setelah tersangka terlihat, pembersihannya punya alat resmi masing-masing:

Kasus 2: File Dihapus tetapi Ruang Tak Kembali #

Pola paling membingungkan: berkas raksasa sudah dihapus, ls tidak lagi menampilkannya, tetapi df tetap melaporkan disk penuh. Mekanismenya sederhana: di Linux, ruang disk baru benar-benar dikembalikan saat tidak ada proses yang masih memegang berkas itu. Proses yang membuka berkas besar lalu berkasnya dihapus akan terus memegang datanya sampai proses itu ditutup — pola khas server aplikasi dengan log yang dihapus manual. Mekanisme tersebut bisa kita lihat langsung tanpa lsof:

dd if=/dev/zero of=besar.tmp bs=1024 count=100 status=none
exec 9>besar.tmp
rm besar.tmp
if [ -e besar.tmp ]; then echo "masih terlihat"; else echo "entri sudah hilang, ruang masih dipunya proses ini"; fi
exec 9>&-
echo "descriptor 9 ditutup: ruang kini benar-benar bebas"

Output yang Dihasilkan:

entri sudah hilang, ruang masih dipunya proses ini
descriptor 9 ditutup: ruang kini benar-benar bebas

Baris exec 9>besar.tmp membuka berkas itu dan menyimpan handlenya di descriptor 9 milik shell — rm kemudian menghapus entrinya, tetapi selama descriptor itu terbuka, kernel tidak membebaskan datanya. Perintah lsof +L1 di mesin sungguhan mendaftar persis kondisi ini: berkas dengan link count di bawah satu yang masih diproces. Solusinya bukan menghapus lagi, melainkan mematikan atau me-restart proses pemegangnya, lalu memverifikasi dengan df bahwa ruangnya kembali.

Perburuan ruang selalu berakhir dengan dua pilihan: hapus yang aman dihapus, atau pindahkan isinya. Dua-duanya menuntut kita menyentuh berkas milik berbagai user dan service — dan tidak lama kemudian pesan berikutnya menyambut: Permission denied. Kita bedah cara membaca dan memperbaikinya di Chapter Permission Errors .

Referensi lanjut: du(1) , df(1) , dan find(1) untuk opsi lengkap ketiga alat perburukan.