Server Masih Punya Space Tapi Stuck? Ternyata Ini Pelakunya!

Beberapa waktu lalu, saya mengalami kejadian menarik di salah satu server yang saya kelola. Tiba-tiba saja server tersebut terasa sangat lambat bahkan sempat stuck, padahal saat dicek menggunakan perintah df -h, kapasitas disk masih terlihat aman — masih banyak ruang tersisa. Awalnya saya pikir mungkin ada proses yang berat atau ada kesalahan konfigurasi, tapi setelah ditelusuri lebih dalam, ternyata masalahnya bukan di space, melainkan di inode!

Pengalaman ini cukup membuka wawasan saya, karena sering kali kita hanya fokus pada penggunaan disk space tanpa memperhatikan sisi lain yang juga penting, yaitu jumlah inode yang tersedia di sistem file. Nah, melalui tulisan ini saya ingin berbagi sedikit cerita sekaligus penjelasan ringan tentang bagaimana inode bisa penuh meskipun disk masih longgar, dan apa dampaknya terhadap performa server.

Mengenal df -h: Cara Mudah Melihat Penggunaan Disk Space

Langkah pertama yang biasanya saya lakukan ketika server mulai terasa lambat adalah mengecek kapasitas penyimpanan. Perintah yang paling sering saya gunakan untuk itu adalah df -h.

Bagi yang belum familiar, df sendiri adalah singkatan dari disk free, dan berfungsi untuk menampilkan informasi mengenai penggunaan ruang penyimpanan di sistem. Tambahan opsi -h berarti human readable, yaitu membuat hasilnya lebih mudah dibaca manusia — misalnya menampilkan ukuran dalam satuan seperti MB, GB, atau TB, bukan dalam angka blok yang sulit dipahami.

Dengan menjalankan df -h, saya bisa langsung melihat berapa banyak kapasitas disk yang sudah terpakai, berapa yang masih kosong, serta di partisi mana file-file itu berada. Biasanya, kalau ada partisi yang mendekati 100% penggunaan, itu sudah jadi tanda bahaya karena sistem bisa berhenti menulis data baru.

Namun, dalam kasus saya kemarin, hasil df -h ternyata masih aman. Tidak ada partisi yang penuh, ruang kosong masih banyak, dan secara logika seharusnya server tetap berjalan lancar. Tapi anehnya, sistem tetap tidak bisa menulis file baru dan beberapa service tiba-tiba berhenti bekerja. Dari situ saya mulai curiga — mungkin bukan disk space-nya yang habis, tapi ada hal lain yang penuh di balik layar.

Lalu, Apa Itu df -i dan Mengapa Penting?

Setelah hasil dari df -h terlihat aman, saya jadi penasaran apa yang sebenarnya terjadi. Akhirnya, saya mencoba menjalankan perintah lain yang jarang saya pakai, yaitu df -i.

Nah, kalau df -h menampilkan informasi tentang kapasitas penyimpanan dalam ukuran data (seperti GB atau TB), maka df -i menunjukkan penggunaan inode.
Inode bisa dibilang sebagai “identitas” dari setiap file dan folder di sistem Linux. Setiap kali kita membuat file baru, sistem akan membuat satu inode untuk menyimpan metadata tentang file tersebut — seperti pemiliknya, izin akses, dan lokasi data di disk.

Masalahnya, jumlah inode dalam satu sistem file itu terbatas. Jadi meskipun ruang disk masih banyak, kalau semua inode sudah terpakai, sistem tidak bisa membuat file baru. Ini artinya, walaupun df -h menunjukkan masih ada ruang kosong, server tetap bisa “macet” karena sudah kehabisan inode.

Waktu saya cek hasil df -i, ternyata persentase penggunaan inode sudah 100%! Di situlah saya sadar, penyebab server stuck bukan karena disk penuh, tapi karena terlalu banyak file kecil yang memakan inode. Biasanya hal seperti ini terjadi jika ada direktori yang berisi jutaan file log, cache, atau file sementara yang tidak pernah dibersihkan.

Mengenal Lebih Dalam: Apa Itu Inode?

Setelah melihat hasil df -i yang menunjukkan angka 100%, saya akhirnya mulai mencari tahu lebih jauh tentang apa sebenarnya inode itu.
Singkatnya, inode adalah struktur data di sistem file Linux yang menyimpan informasi penting tentang setiap file dan direktori — tapi bukan isinya.

Kalau diibaratkan, inode itu seperti kartu identitas (ID) untuk setiap file. Di dalamnya tersimpan data seperti:

• siapa pemilik file (user dan group),

• izin akses (read, write, execute),

• ukuran file,

• waktu pembuatan dan modifikasi,

• serta lokasi blok data file di disk.

Namun, inode tidak menyimpan nama file. Nama file justru disimpan di direktori yang menghubungkan nama tersebut ke nomor inode tertentu. Jadi, setiap file yang kita lihat di sistem Linux sebenarnya adalah kombinasi antara nama file dan inode yang menunjuk ke data aslinya.

Yang menarik, jumlah inode sudah ditentukan saat sistem file dibuat. Jadi, misalnya satu partisi dibuat dengan 10 juta inode, maka sistem hanya bisa memiliki maksimal 10 juta file dan direktori di partisi itu — tidak peduli ukuran file-nya besar atau kecil.
Artinya, jika banyak file kecil (misalnya log atau cache kecil-kecil), inode bisa cepat habis walaupun disk space masih longgar.

Waktu saya menyadari hal ini, saya baru paham mengapa server saya tiba-tiba tidak bisa menulis file baru. Ruang disk memang masih ada, tapi “slot identitas” untuk file baru sudah tidak tersedia.

Bagaimana Cara Menghitung dan Melihat Penggunaan Inode?

Setelah tahu apa itu inode dan kenapa bisa habis, saya jadi penasaran: sebenarnya bagaimana cara menghitung atau melihat berapa banyak inode yang sedang digunakan di sistem?

Untungnya, Linux sudah menyediakan cara yang cukup sederhana untuk mengeceknya, yaitu dengan perintah yang sebelumnya saya sebut:

Perintah ini akan menampilkan daftar semua partisi lengkap dengan jumlah total inode, berapa yang sudah digunakan, dan berapa yang masih tersedia. Biasanya hasilnya terlihat seperti ini:

Dari contoh di atas, bisa dilihat bahwa total inode di partisi / ada sekitar 6,5 juta. Yang sudah terpakai sekitar 6,54 juta, dan yang tersisa cuma 10 ribuan — itulah sebabnya IUse% jadi 100%.

Kalau ingin menghitung rasio penggunaan inode, rumus sederhananya seperti ini:

Misalnya dari data di atas:

Jadi memang sudah hampir penuh.

Selain itu, kalau kamu ingin tahu folder mana yang paling banyak memakan inode, kamu bisa menggunakan kombinasi perintah seperti ini:

Perintah ini menghitung berapa banyak file (bukan ukurannya) di dalam direktori tersebut. Semakin banyak jumlah file, semakin banyak pula inode yang digunakan. Biasanya direktori seperti /var/log, /tmp, atau direktori cache aplikasi adalah “tersangka utama” penyebab inode penuh.

Apakah Kapasitas RAM, CPU, atau Storage Berpengaruh ke Inode?

Setelah saya tahu bahwa inode bisa habis, saya sempat berpikir: apakah jumlah inode ini bisa dipengaruhi oleh kapasitas RAM, CPU, atau ukuran storage di server?
Jawabannya: tidak secara langsung, tapi ada kaitannya dari sisi jenis sistem file dan ukuran partisi.

Jadi begini—
Jumlah inode tidak tergantung pada RAM atau CPU. RAM dan CPU berperan dalam hal kinerja server: seberapa cepat proses berjalan, berapa banyak proses bisa dijalankan bersamaan, dan sebagainya.
Sedangkan inode lebih berhubungan dengan struktur sistem file di storage (misalnya ext4, xfs, btrfs, dsb).

Ketika kita membuat partisi dan memformatnya, sistem file akan menentukan jumlah inode secara otomatis berdasarkan ukuran partisi dan parameter tertentu. Misalnya pada sistem file ext4, biasanya sistem akan membuat sekitar 1 inode untuk setiap 16 KB dari kapasitas disk.
Artinya, semakin besar storage yang diformat, semakin banyak inode yang dibuat — tapi itu tidak bisa berubah setelah partisi dibuat (kecuali diformat ulang).

Jadi kalau disimpulkan:

• RAM tidak memengaruhi jumlah inode.

• CPU juga tidak memengaruhi inode.

• Storage hanya memengaruhi inode saat pertama kali diformat, karena jumlah inode dihitung dari ukuran partisi dan konfigurasi sistem file.

Namun, hubungan tidak langsungnya adalah — kalau inode penuh, server bisa jadi lambat atau bahkan gagal menulis file, yang akhirnya bisa terlihat seperti masalah CPU atau RAM tinggi. Tapi akar masalahnya tetap di inode, bukan di performa hardware.

Menemukan Folder atau File yang Memakan Banyak Inode

Setelah tahu bahwa inode bisa habis karena terlalu banyak file kecil, langkah berikutnya yang saya lakukan adalah mencari folder mana yang menjadi penyebab utamanya. Biasanya, masalah ini muncul di direktori yang sering dipakai sistem atau aplikasi untuk menyimpan log, cache, atau file sementara.

Beberapa contoh umum di Linux antara lain:

• /var/log → tempat berbagai log sistem dan aplikasi.

• /tmp → direktori untuk file sementara.

• /var/spool → sering digunakan oleh mail server atau sistem antrian.

• Direktori cache dari aplikasi tertentu (misalnya /var/cache, atau direktori khusus milik web server).

Untuk mencari tahu lokasi yang memakan inode paling banyak, saya biasanya menggunakan beberapa perintah berikut ini:

🔹 1. Mengecek jumlah file per direktori

Perintah sederhana ini membantu menghitung jumlah file di dalam suatu folder (tanpa melihat ukurannya):

Misalnya:

Perintah di atas akan menghitung berapa banyak file di /var/log. Kalau hasilnya ribuan atau bahkan jutaan, besar kemungkinan folder itulah penyebab inode penuh.

🔹 2. Menampilkan folder dengan jumlah file terbanyak

Kalau ingin mencari tahu direktori mana yang punya file paling banyak secara cepat, bisa gunakan kombinasi perintah berikut:

Perintah ini akan menampilkan daftar direktori beserta jumlah file di dalamnya, lalu mengurutkannya dari yang paling banyak. Biasanya saya cukup melihat 5–10 direktori teratas saja untuk menemukan sumber masalahnya.

🔹 3. Mengecek ukuran direktori (jika ingin tahu besar datanya juga)

Kadang bukan hanya jumlah file yang penting, tapi juga ukuran totalnya. Untuk itu saya gunakan:

Perintah ini menampilkan ukuran setiap folder di root (/) dan mengurutkannya dari yang kecil ke besar.
Dari situ saya bisa tahu apakah ada direktori besar yang mungkin berisi banyak file log atau cache.

Biasanya setelah menjalankan beberapa perintah di atas, saya bisa menemukan “biang kerok”-nya — misalnya folder log yang berisi ribuan file kecil yang tidak pernah dibersihkan. Dari sana baru saya lanjut ke tahap pembersihan inode supaya server kembali normal.

Membersihkan dan Mencegah Inode Penuh

Setelah menemukan folder penyebab inode penuh, langkah berikutnya tentu adalah membersihkannya dengan aman. Tapi sebelum mulai hapus sana-sini, saya biasanya melakukan pengecekan ulang agar tidak menghapus file penting milik sistem atau aplikasi. Berikut langkah-langkah yang biasa saya lakukan:

1. Bersihkan file log lama

Folder yang paling sering menyebabkan inode penuh biasanya adalah /var/log.
Untuk membersihkan log yang sudah terlalu lama, saya menggunakan perintah seperti ini:

Perintah di atas akan menghapus file log yang lebih dari 7 hari. Kamu bisa ubah angka 7 sesuai kebutuhan.

Kalau server kamu menggunakan sistem logrotate, pastikan konfigurasi rotasi log sudah aktif agar file log otomatis dikompresi dan dihapus setelah beberapa waktu. Konfigurasinya biasanya ada di:

atau

2. Hapus file sementara atau cache

Direktori seperti /tmp dan /var/tmp juga sering berisi file kecil yang menumpuk dari proses sementara aplikasi.
Untuk membersihkannya:

Perintah ini menghapus file di /tmp yang sudah tidak diakses selama lebih dari 3 hari.
Selain itu, beberapa aplikasi juga memiliki folder cache sendiri, misalnya:

• Web server (seperti Nginx atau Apache)

• Package manager (/var/cache/apt/archives atau /var/cache/yum)

• Aplikasi web (misalnya /var/www/html/cache)

Cache biasanya aman dihapus, tapi sebaiknya pastikan dulu bahwa aplikasi sedang tidak menggunakannya.

3. Hapus file atau direktori kosong

Kadang inode juga terpakai untuk folder kosong. Kamu bisa mencari dan menghapus folder kosong dengan:

4. Automasi dengan cron job

Agar tidak perlu melakukan pembersihan manual terus-menerus, saya biasanya membuat cron job sederhana agar sistem membersihkan file lama secara otomatis.
Misalnya, buat file baru di /etc/cron.daily/cleanup-temp:

Lalu beri izin eksekusi:

Dengan begitu, sistem akan otomatis menjalankan pembersihan setiap hari.

5. Pencegahan jangka panjang

Untuk mencegah inode penuh di masa depan, saya biasanya melakukan beberapa hal berikut:

• Memantau inode usage secara berkala dengan df -i.

• Mengaktifkan rotasi log otomatis.

• Menjaga agar direktori cache tidak dibiarkan menumpuk.

• Membatasi jumlah file kecil yang dihasilkan aplikasi (misalnya dengan sistem batching atau kompresi).

Penutup

Dari pengalaman ini, saya jadi belajar bahwa disk penuh tidak selalu soal ruang penyimpanan, tapi bisa juga karena inode yang habis.
Kadang kita terlalu fokus melihat df -h tanpa pernah mengecek df -i, padahal keduanya sama-sama penting untuk menjaga kesehatan server.

Sekarang, setiap kali saya melakukan pengecekan rutin, saya selalu memastikan dua hal: ruang disk dan jumlah inode. Dengan begitu, saya bisa mencegah masalah lebih awal sebelum server benar-benar “macet” lagi.