Inode Penuh Padahal Disk Masih Lega, Kok Bisa?

Situasinya kira-kira begini. Aplikasi tiba-tiba gagal menyimpan file, log berhenti tertulis, dan pesan yang muncul adalah No space left on device. Kamu menjalankan df -h, dan disk ternyata masih terisi separuh. Membingungkan, karena tidak ada yang terlihat penuh.

Penyebabnya sering kali inode yang habis. Disk bukan hanya kehabisan ruang ketika kapasitasnya terpakai, tetapi juga ketika jatah "nomor file" sudah habis dibagikan. Begitu itu terjadi, sistem tidak bisa membuat file baru sekecil apa pun, meskipun ruang kosongnya masih puluhan gigabyte.

Apa itu inode?

Inode adalah catatan kecil yang menyimpan informasi tentang sebuah file: pemilik, izin akses, ukuran, waktu diubah, dan lokasi datanya di disk. Nama file sendiri tidak disimpan di inode, melainkan di direktori yang menunjuk ke inode tersebut. Setiap file, folder, dan symlink memakai satu inode.

Di filesystem ext4, yang paling umum dipakai di server Ubuntu dan Debian, jumlah inode ditetapkan saat partisi diformat berdasarkan rasio ukuran disk per inode. Setelah itu jumlahnya tetap. Artinya, sebuah disk bisa kehabisan inode bila isinya berupa jutaan file yang sangat kecil, jauh sebelum kapasitasnya terpakai.

Filesystem lain berperilaku berbeda. XFS, bawaan AlmaLinux dan Rocky Linux, mengalokasikan inode secara dinamis sesuai kebutuhan, dengan batas persentase tertentu dari ruang disk. Btrfs juga dinamis. Karena itu, kasus inode habis paling sering ditemui di ext4.

Cara memastikan inode yang habis

Perintahnya sederhana:

df -i

Kolom IUsed dan IUse% menunjukkan berapa inode yang terpakai. Bila IUse% di partisi tertentu mendekati atau mencapai 100 persen, sementara df -h masih lega, penyebabnya sudah pasti.

Gejala lain yang sering menyertai: sesi login website tiba-tiba hilang, upload gambar gagal, email tidak bisa diterima, atau proses update paket berhenti di tengah jalan. Semua itu terjadi karena aplikasi tidak bisa membuat file baru. Di partisi XFS, kolom inode juga tampil di df -i, tetapi angkanya bisa berubah seiring pemakaian disk karena alokasinya dinamis.

Langkah berikutnya mencari folder yang berisi file paling banyak. GNU coreutils menyediakan opsi untuk menghitung inode per folder:

du --inodes -x -d 1 / 2>/dev/null | sort -n | tail -n 15

Opsi -x membuat pencarian tetap di partisi yang sama, sehingga folder dari disk lain tidak ikut terhitung. Ulangi perintah itu ke folder dengan angka terbesar, misalnya /var, lalu /var/lib, sampai ketemu folder yang isinya membengkak. Kalau kamu belum hafal fungsi tiap folder, artikel struktur folder Linux dari /etc sampai /var bisa membantu menebak isinya.

Setelah folder tersangka ketemu, hitung isinya dengan find /path/folder -type f | wc -l. Angka ratusan ribu atau jutaan di folder yang seharusnya hanya berisi sedikit file adalah konfirmasi yang kamu cari. Perhatikan juga tanggal file terlama dengan ls -ltr | head di folder itu, supaya kamu tahu sejak kapan penumpukan terjadi.

Tersangka yang paling sering ditemukan

Pola yang terlihat di berbagai server hampir selalu sama: ada proses yang membuat file kecil terus-menerus, tetapi tidak ada yang membersihkannya.

Sesi PHP adalah tersangka klasik. Di Ubuntu dan Debian, PHP tidak membersihkan sesi lewat mekanisme bawaannya, melainkan lewat timer phpsessionclean. Bila folder sesi dipindah ke lokasi lain atau timer itu tidak berjalan, file sesi bisa menumpuk sampai jutaan. Cek dengan systemctl status phpsessionclean.timer.

Untuk Docker, panduan membersihkan sisa image dan volume ada di artikel membersihkan image dan volume Docker yang menumpuk.

Membersihkan jutaan file dengan aman

Saat file sudah jutaan, rm * biasanya gagal dengan pesan Argument list too long, karena terlalu banyak nama file untuk satu perintah. Gunakan find yang menghapus file satu per satu tanpa batas itu, misalnya untuk file lebih tua dari tujuh hari:

find /var/lib/php/sessions -type f -mtime +7 -delete

Selalu jalankan perintah yang sama tanpa -delete terlebih dahulu dan periksa hasilnya, supaya kamu yakin yang terhapus memang file yang dimaksud. Penghapusan jutaan file bisa memakan waktu dan membebani disk, jadi lakukan di jam sepi bila memungkinkan.

Setelah inode kembali lega, aplikasi biasanya langsung bisa menulis lagi. Restart layanan yang sempat error bila masih menampilkan masalah.

Mencegahnya terulang

Menghapus file hanya menyelesaikan kejadian hari ini. Supaya tidak terulang, cari proses yang membuat file itu dan pastikan ada mekanisme pembersihan, entah dari aplikasinya sendiri, logrotate, timer systemd, atau jadwal cron. Contoh menyusun jadwal pembersihan ada di artikel membuat cron job di Linux.

Tambahkan juga pemantauan inode, bukan hanya kapasitas disk. Banyak alat monitoring hanya memberi peringatan saat disk hampir penuh, sehingga inode yang habis datang tanpa tanda. Untuk masalah kapasitas biasa, langkahnya dibahas di artikel mencari dan membersihkan disk server yang penuh.

Bila server memang dirancang menyimpan jutaan file kecil, misalnya penyimpanan gambar atau mail server, jumlah inode perlu direncanakan sejak awal. Di ext4, jumlah inode bisa diatur saat format dengan opsi -i atau -N pada mkfs.ext4, dan bertambah bila partisi diperbesar. Menambah inode pada partisi yang ada tanpa memperbesarnya tidak bisa dilakukan, kecuali dengan memformat ulang.

Ringkasnya

Pesan "disk penuh" padahal ruang masih lega hampir selalu berarti inode habis. Pastikan dengan df -i, cari folder pembengkak dengan du --inodes, hapus file lama dengan find, lalu perbaiki sumbernya supaya file kecil tidak menumpuk lagi. Masukkan pemakaian inode ke daftar metrik yang dipantau, sejajar dengan kapasitas disk.

Kalau websitemu ada di shared hosting, batas inode biasanya berupa kuota dari paket hosting, bukan dari ukuran disk. Penjelasannya ada di apa itu inode hosting dan kenapa bisa penuh.