Pertanyaan dan cakupan
Penggunaan bita yang normal tidak membuktikan bahwa sistem file dapat membuat file lain. ext4 dan sistem file serupa mengelola blok data dan inode; jutaan file kecil, fragmen cache, antrean email, atau layer kontainer dapat menghabiskan inode terlebih dahulu. Tugasnya adalah menemukan penyebabnya saat layanan sedang berjalan, tanpa menghapus direktori yang tidak dikenal atau menyembunyikan bukti dengan melakukan restart.
Materi wawancara publik Linux dan DevOps sering menggunakan "disk penuh" sebagai skenario diagnostik. Manual df dan dokumentasi ext4 kernel Linux mendefinisikan batas antara blok, inode, dan entri direktori, sehingga jawaban yang kuat menyimpulkan tindakan dari bukti alih-alih sekadar menghafal perintah pembersihan.
Apa yang sedang diuji oleh pewawancara
- Membedakan blok bita, inode, kuota pengguna/proyek, dan layer kontainer yang dapat ditulisi (writable layer).
- Mengonfirmasi mount yang terpengaruh, jendela waktu, dan jalur penulisan sebelum mengambil tindakan.
- Menemukan hotspot file kecil, mount tersembunyi, celah rotasi, dan file yang dihapus saat masih terbuka.
- Memilih langkah pemulihan yang dapat dibatalkan (reversible) dan dapat diaudit alih-alih
rm -rfatau restart membabi buta. - Memantau penggunaan inode, pertumbuhan jumlah file, dan hotspot direktori sebagai sinyal kapasitas.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Ke jalur dan mount mana proses yang gagal tersebut menulis? Apakah itu host, kontainer, atau sistem file sementara?
- Apa yang dilaporkan oleh
df -hdandf -i? Apakah kuota pengguna atau proyek terlibat? - Apakah kegagalan terjadi saat membuat file, memperluas file, atau menulis ke overlay, tmpfs, atau sistem file jaringan?
- Apakah proses deploy, rotasi log, pencadangan, atau batch job sedang berjalan? Apakah aturan retensi membatasi penghapusan?
- Bisakah layanan dibatasi sementara (throttled), dan apakah ada jendela rollback atau health-check?
Jawaban 30 detik
"Saya akan memastikan proses yang gagal, mount, dan jendela waktunya, lalu membandingkan df -h dengan df -i. Jika penggunaan inode mendekati 100%, saya akan mencari hotspot jumlah file dan memeriksa layer kontainer yang dapat ditulisi, rotasi log, dan kuota. Jika inode dalam kondisi sehat, saya akan memeriksa blok, ruang yang dicadangkan, kuota, dan file yang dihapus tetapi masih terbuka. Pemulihan akan dimulai dengan rotasi terkontrol, kompresi, pembersihan data sementara yang telah dikonfirmasi, atau ekspansi sambil tetap mempertahankan bukti. Terakhir, saya akan memasang peringatan (alert) pada bita, inode, jumlah file, laju pertumbuhan, dan waktu untuk remediasi alih-alih hanya satu persentase disk."
Jawaban mendalam
Langkah 1: Tetapkan batas kesalahan (fault boundary)
Pertahankan log aplikasi dan kernel, jalur yang gagal, serta informasi mount. Tentukan apakah satu layanan, satu kontainer, atau host yang tidak dapat membuat file. Teks kesalahan yang sama dapat merepresentasikan habisnya inode, blok, kuota, atau sistem file yang bersifat read-only.
Langkah 2: Periksa blok dan inode secara bersamaan
df -hT /
df -iT /
findmnt -T /var/lib/appdf -h melaporkan blok data dan df -i melaporkan inode. Baca keduanya untuk mount yang memiliki jalur yang gagal tersebut. Jika penggunaan inode mendekati 100% sementara bita masih tersisa, prioritaskan analisis file kecil; jika tidak, periksa blok, kuota, status read-only, dan batas kontainer.
Langkah 3: Temukan hotspot direktori berdasarkan jumlah
Hitung entri direktori sebelum membaca konten file untuk menghindari I/O yang tidak perlu. Persempit pencarian berdasarkan direktori dan telusuri cabang yang tumbuh paling cepat. Batasi find pada jalur yang diketahui, kecualikan mount lain, dan berikan anggaran sumber daya untuk penelusuran selama lalu lintas puncak. Direktori yang penuh dengan file-file kecil dapat menghabiskan inode meskipun hanya menggunakan sedikit ruang bita.
Langkah 4: Pisahkan file dari batas mount
Sistem file overlay, bind mount, tmpfs, dan volume log dapat membuat jalur host berbeda dari layer tempat proses menulis. Periksa silang direktori kerja proses, konfigurasi kontainer, dan findmnt -T. Jangan menghapus file layer kontainer dari host; gunakan runtime, kebijakan volume, atau jalur pembersihan aplikasi.
Langkah 5: Periksa rotasi, cache, dan file yang dihapus tetapi masih terbuka
Rotasi mungkin mengubah nama log tanpa membuat proses membukanya kembali, dan cache dapat membuat file kecil tanpa batas. lsof +L1 menemukan file dengan tautan direktori nol yang masih ditahan oleh suatu proses. Melepaskannya biasanya mengharuskan pemilik untuk menutup atau membuka kembali file tersebut dengan aman. Restart bukanlah opsi bawaan (default) karena menghancurkan bukti dan dapat mereproduksi lonjakan penulisan (write storm).
Langkah 6: Pilih tindakan pemulihan
Urutkan tindakan berdasarkan risiko: batasi (throttle) produsen non-kritis, rotasi atau kompres log yang telah dikonfirmasi, bersihkan cache yang tercakup dalam kebijakan retensi, lalu lakukan ekspansi atau migrasi. Catat setiap jalur, ukuran, jumlah file, pemilik, dan langkah rollback. Sebelum menghapus, verifikasi bahwa data tersebut bukanlah konfigurasi saat ini, status antrean, materi database, atau bukti audit.
Langkah 7: Verifikasi pemulihan dan efek samping
Jalankan kembali df -hT dan df -iT, lalu lakukan pembuatan file sementara yang sebenarnya, penulisan log, dan permintaan kritis. Konfirmasikan bahwa penggunaan inode, tingkat kesalahan, dan latensi telah pulih. Untuk kontainer, verifikasi bahwa melakukan rebuild atau restart tidak langsung menciptakan kembali lonjakan jumlah file.
Langkah 8: Bangun pertahanan yang tahan lama
Pantau penggunaan blok dan inode, file per mount, pertumbuhan direktori, penundaan rotasi, file yang dihapus tetapi masih terbuka, dan ukuran layer kontainer. Tetapkan ambang batas dari laju pertumbuhan dan waktu respons, bukan dari satu angka 90% universal. Masukkan pembersihan, ekspansi, pemulihan rotasi, dan verifikasi ke dalam runbook yang dapat dieksekusi dan latih runbook tersebut.
Pertukaran (trade-off) dan batasan
Pembersihan versus ekspansi
Pembersihan memulihkan layanan dengan cepat tetapi masalah dapat berulang; ekspansi menambah ruang luang tanpa memperbaiki penyebab utamanya. Pulihkan terlebih dahulu, lalu gunakan bukti pertumbuhan untuk memilih perubahan aplikasi, rotasi, granularitas file, atau ekspansi.
Akurasi pengukuran versus biaya online
find pada seluruh disk memang presisi tetapi memakan banyak sumber daya. Penghitungan direktori dan pengambilan sampel lebih cocok untuk pemantauan berkelanjutan. Selama insiden, persempit cakupan secara bertahap alih-alih membaca seluruh sistem file secara rekursif di bawah tekanan I/O.
Host versus kontainer
Metrik host tidak menggantikan metrik volume dan overlay. Setiap layer yang dapat ditulisi memerlukan kuota, pemilik, dan batas pembersihan; penghapusan lintas-layer dapat menimbulkan perilaku image atau volume yang tidak terduga.
Latihan kegagalan dan evolusi
Kegagalan: hanya melihat df -h
Bita dapat tersisa sementara inode bernilai nol. Sertakan df -i dalam diagnostik respons pertama dan riwayat peringatan berdasarkan mount.
Kegagalan: rm -rf direktori terbesar
Direktori tersebut mungkin berisi antrean, bukti, atau file yang sedang ditulis. Konfirmasikan kepemilikan, retensi, handle yang terbuka, dan rollback, lalu bersihkan dalam batch yang dibatasi.
Kegagalan: restart alih-alih memulihkan
Restart dapat melepaskan file yang dihapus tetapi masih terbuka untuk sementara waktu, namun menghancurkan bukti dan menyembunyikan penyebabnya. Biarkan pemilik menutup file dengan aman dan verifikasi penulisan berikutnya.
Kesalahan umum dan pertanyaan lanjutan
Kesalahan: penggunaan inode hanya berkaitan dengan ukuran file
Inode terutama dikonsumsi oleh jumlah file dan format sistem file; file berukuran nol bita dan file kecil tetap mengonsumsinya.
Pertanyaan lanjutan: mengapa menghapus file tidak membebaskan ruang?
Proses masih menahan deskriptor filenya. Entri direktori telah hilang, tetapi blok dan inode tetap teralokasi hingga deskriptor tersebut ditutup.
Pertanyaan lanjutan: bagaimana cara membedakan kuota?
Bandingkan metrik seluruh sistem file dengan kuota pengguna, proyek, dan kontainer, lalu jalankan pengujian pembuatan terkontrol dengan identitas yang sama pada jalur yang sama.
Pertanyaan lanjutan: bagaimana cara memvalidasi rotasi log?
Verifikasi bahwa proses membuka file baru, menutup handle lama, serta jumlah file dan penggunaan inode berada dalam batas anggaran; nama file baru saja bukanlah sebuah bukti.
Pertanyaan lanjutan: bagaimana cara mencegah lonjakan file kecil (small-file storm)?
Kumpulkan data dalam batch, partisi berdasarkan waktu, batasi entri cache, tetapkan batas rotasi, dan pantau laju pembuatan file serta pertumbuhan entri direktori.
Pertanyaan lanjutan: kapan ekspansi tidak membantu?
Jika kepadatan inode bersifat tetap dan sistem file baru menyediakan desain inode yang sama, menambahkan bita tidak akan menyelesaikan masalah habisnya inode. Lakukan migrasi, bangun ulang (rebuild), atau ubah granularitas file.