Temu Bual Umum: Bagaimana Anda Mendiagnosis Kehabisan Inode Apabila Ruang Cakera Masih Ada?

Soalan dan skop

Penggunaan bait yang normal tidak membuktikan bahawa sistem fail boleh mencipta fail lain. ext4 dan sistem fail yang serupa menguruskan blok data dan inode; berjuta-juta fail kecil, serpihan cache, giliran mel, atau lapisan kontena boleh menghabiskan inode terlebih dahulu. Tugasnya adalah untuk mencari punca semasa perkhidmatan sedang berjalan, tanpa memadamkan direktori yang tidak diketahui atau menyembunyikan bukti melalui permulaan semula (restart).

Bahan temu bual Linux dan DevOps awam sering menggunakan "cakera penuh" sebagai senario diagnostik. Manual df dan dokumentasi kernel Linux ext4 mentakrifkan sempadan antara blok, inode, dan entri direktori, jadi jawapan yang mantap merumuskan tindakan berdasarkan bukti dan bukannya sekadar menghafal arahan pembersihan.

Perkara yang diuji oleh penemu bual

Membezakan blok bait, inode, kuota pengguna/projek, dan lapisan boleh tulis kontena.
Mengesahkan lekapan yang terjejas, tetingkap masa, dan laluan penulisan sebelum mengambil tindakan.
Mencari titik panas fail kecil, lekapan tersembunyi, kelompangan penggiliran, dan fail yang dipadam semasa masih dibuka.
Memilih langkah pemulihan yang boleh diundur (reversible) dan boleh diaudit dan bukannya rm -rf atau permulaan semula secara membuta tuli.
Memantau penggunaan inode, pertumbuhan bilangan fail, dan titik panas direktori sebagai isyarat kapasiti.

Soalan untuk dijelaskan terlebih dahulu

Laluan dan lekapan manakah yang cuba ditulis oleh proses yang gagal? Adakah ia hos, kontena, atau sistem fail sementara?
Apakah yang dilaporkan oleh df -h dan df -i? Adakah kuota pengguna atau projek terlibat?
Adakah kegagalan tersebut berlaku semasa mencipta fail, memanjangkan fail, atau menulis ke overlay, tmpfs, atau sistem fail rangkaian?
Adakah proses penggunaan (deploy), penggiliran log, sandaran, atau tugas kelompok sedang berjalan? Adakah peraturan pengekalan mengehadkan pemadaman?
Bolehkah perkhidmatan tersebut dicekik (throttled) seketika, dan adakah terdapat tetingkap pemulihan (rollback) atau pemeriksaan kesihatan?

Jawapan 30 saat

"Saya akan mengenal pasti proses, lekapan, dan tetingkap masa yang gagal, kemudian membandingkan df -h dengan df -i. Jika penggunaan inode hampir 100%, saya akan mencari titik panas bilangan fail dan memeriksa lapisan boleh tulis kontena, penggiliran log, dan kuota. Jika inode berada dalam keadaan sihat, saya akan memeriksa blok, ruang rizab, kuota, dan fail dipadam-dibuka. Pemulihan akan bermula dengan penggiliran terkawal, pemampatan, pembersihan data sementara yang disahkan, atau pengembangan sambil mengekalkan bukti. Akhir sekali, saya akan menetapkan amaran untuk bait, inode, bilangan fail, kadar pertumbuhan, dan masa untuk pemulihan dan bukannya satu peratusan cakera semata-mata."

Jawapan mendalam

Langkah 1: Tetapkan sempadan kerosakan

Kekalkan log aplikasi dan kernel, laluan yang gagal, dan maklumat lekapan. Tentukan sama ada satu perkhidmatan, satu kontena, atau hos yang tidak dapat mencipta fail. Teks ralat yang sama boleh mewakili kehabisan inode, blok, kuota, atau sistem fail baca sahaja.

Langkah 2: Periksa blok dan inode bersama-sama

bash

df -hT /
df -iT /
findmnt -T /var/lib/app

df -h melaporkan blok data dan df -i melaporkan inode. Baca kedua-duanya untuk lekapan yang memiliki laluan yang gagal. Jika penggunaan inode hampir 100% manakala bait masih ada, utamakan analisis fail kecil; jika tidak, periksa blok, kuota, keadaan baca sahaja, dan had kontena.

Langkah 3: Cari titik panas direktori mengikut kiraan

Kira entri direktori sebelum membaca kandungan fail untuk mengelakkan I/O yang tidak perlu. Persempit carian mengikut direktori dan telusuri cabang yang berkembang paling cepat. Hadkan find kepada laluan yang diketahui, kecualikan lekapan lain, dan berikan belanjawan sumber untuk penelusuran semasa trafik puncak. Direktori yang penuh dengan fail kecil boleh menggunakan inode sambil menggunakan sedikit ruang bait.

Langkah 4: Asingkan fail daripada sempadan lekapan

Sistem fail overlay, lekapan bind, tmpfs, dan volum log boleh menyebabkan laluan hos berbeza daripada lapisan tempat proses menulis. Semak silang direktori kerja proses, konfigurasi kontena, dan findmnt -T. Jangan padam fail lapisan kontena daripada hos; gunakan masa jalan (runtime), dasar volum, atau laluan pembersihan aplikasi.

Langkah 5: Periksa penggiliran, cache, dan fail dipadam-dibuka

Penggiliran mungkin menamakan semula log tanpa membuat proses membukanya semula, dan cache mungkin mencipta fail kecil tanpa had. lsof +L1 mencari fail dengan pautan direktori sifar yang masih dipegang oleh sesuatu proses. Melepaskannya biasanya memerlukan pemilik menutup atau membuka semula fail tersebut dengan selamat. Permulaan semula bukanlah pilihan lalai kerana ia memusnahkan bukti dan mungkin menghasilkan semula lonjakan penulisan.

Langkah 6: Pilih tindakan pemulihan

Susun tindakan mengikut risiko: cekik pengeluar yang tidak kritikal, gilirkan atau mampatkan log yang disahkan, bersihkan cache yang diliputi oleh dasar pengekalan, kemudian kembangkan atau migrasikan. Rekodkan setiap laluan, saiz, bilangan fail, pemilik, dan pemulihan balik. Sebelum pemadaman, sahkan bahawa data tersebut bukan konfigurasi semasa, keadaan giliran, bahan pangkalan data, atau bukti audit.

Langkah 7: Sahkan pemulihan dan kesan sampingan

Jalankan df -hT dan df -iT sekali lagi, kemudian lakukan penciptaan fail sementara sebenar, penulisan log, dan permintaan kritikal. Sahkan bahawa penggunaan inode, kadar ralat, dan kependaman telah pulih. Untuk kontena, sahkan bahawa pembinaan semula atau permulaan semula tidak serta-merta mencipta semula lonjakan bilangan fail.

Langkah 8: Bina pertahanan yang kukuh

Pantau penggunaan blok dan inode, fail bagi setiap lekapan, pertumbuhan direktori, kelewatan penggiliran, fail dipadam-dibuka, dan saiz lapisan kontena. Tetapkan ambang daripada kadar pertumbuhan dan masa tindak balas, bukan satu nombor 90% yang universal. Masukkan pembersihan, pengembangan, pemulihan penggiliran, dan pengesahan ke dalam runbook yang boleh dilaksanakan serta latihkannya.

Pertukaran (trade-off) dan sempadan

Pembersihan berbanding pengembangan

Pembersihan memulihkan perkhidmatan dengan cepat tetapi mungkin berulang; pengembangan menambah ruang tanpa membaiki penjana masalah. Pulihkan terlebih dahulu, kemudian gunakan bukti pertumbuhan untuk memilih perubahan aplikasi, penggiliran, granulariti fail, atau pengembangan.

Ketepatan pengukuran berbanding kos dalam talian

find untuk keseluruhan cakera adalah tepat tetapi mahal. Kiraan direktori dan pensampelan sesuai untuk pemantauan berterusan. Semasa insiden, persempit skop secara progresif dan bukannya membaca keseluruhan sistem fail secara rekursif di bawah tekanan I/O.

Hos berbanding kontena

Metrik hos tidak menggantikan metrik volum dan overlay. Setiap lapisan boleh tulis memerlukan kuota, pemilik, dan sempadan pembersihan; pemadaman merentas lapisan boleh mewujudkan tingkah laku imej atau volum yang tidak dapat diramalkan.

Latih tubi kegagalan dan evolusi

Kegagalan: hanya melihat pada df -h

Bait mungkin masih ada manakala inode adalah sifar. Sertakan df -i dalam diagnostik tindak balas pertama dan sejarah amaran mengikut lekapan.

Kegagalan: rm -rf direktori terbesar

Ia mungkin mengandungi giliran, bukti, atau fail yang sedang ditulis. Sahkan pemilikan, pengekalan, pemegang yang terbuka, dan pemulihan balik, kemudian bersihkan dalam kelompok yang terhad.

Kegagalan: mula semula dan bukannya memulihkan

Permulaan semula mungkin melepaskan fail dipadam-dibuka secara sementara sambil memusnahkan bukti dan menyembunyikan penjana isu. Biarkan pemilik menutup fail dengan selamat dan sahkan penulisan seterusnya.

Kesilapan biasa dan susulan

Kesilapan: penggunaan inode hanya mengenai saiz fail

Inode digunakan terutamanya oleh bilangan fail dan format sistem fail; fail sifar bait dan fail kecil tetap menggunakannya.

Susulan: mengapa memadamkan fail tidak mengosongkan ruang?

Proses masih memegang deskriptor failnya. Entri direktori telah tiada, tetapi blok dan inode kekal diperuntukkan sehingga deskriptor tersebut ditutup.

Susulan: bagaimana anda membezakan kuota?

Bandingkan metrik seluruh sistem fail dengan kuota pengguna, projek, dan kontena, kemudian jalankan ujian penciptaan terkawal sebagai identiti yang sama pada laluan yang sama.

Susulan: bagaimana anda mengesahkan penggiliran log?

Sahkan bahawa proses membuka fail baharu, menutup pemegang lama, dan bilangan fail serta penggunaan inode berada dalam lingkungan belanjawan; nama fail baharu sahaja bukan bukti.

Susulan: bagaimana anda menghalang lonjakan fail kecil?

Kelompokkan rekod, buat pemetakan mengikut masa, hadkan entri cache, tetapkan had penggiliran, dan pantau kadar penciptaan fail serta pertumbuhan entri direktori.

Susulan: bilakah pengembangan tidak membantu?

Jika ketumpatan inode adalah tetap dan sistem fail baharu menyediakan reka bentuk inode yang sama, penambahan bait tidak menyelesaikan masalah kehabisan inode. Lakukan migrasi, bina semula, atau ubah granulariti fail.