題幹與適用場景
位元組使用率正常不等於檔案系統還能建立檔案。ext4 等檔案系統同時管理資料區塊與 inode；大量小檔案、快取碎片、郵件佇列或容器層可能先耗盡 inode。題目要求在服務仍執行時定位根因，不能直接刪除未知目錄或重啟掩蓋證據。
公開 Linux/DevOps 面試資料常把「磁碟滿」作為排障場景；df 文件和 Linux 核心 ext4 文件提供區塊、inode、目錄項之間的事實邊界，因此回答應從可觀測證據推導行動。
面試官考察點
- 能否區分位元組區塊、inode、使用者配額和容器可寫層四種容量邊界。
- 能否先確認受影響掛載點、錯誤時間和寫入路徑，再執行低風險定位。
- 能否定位小檔案熱點、隱藏掛載、日誌輪替缺口，以及刪除後仍被程序持有的檔案。
- 能否選擇可回滾、可稽核的恢復動作，避免
rm -rf和盲目重啟。 - 能否把 inode、檔案數增長和目錄熱點納入容量預算與告警。
回答前需要釐清的問題
- 報錯程序寫入哪個路徑和掛載點？主機、容器、暫存目錄是否相同？
df -h與df -i結果分別是什麼？是否存在使用者或專案配額？- 失敗是建立新檔案、擴展既有檔案，還是寫入 overlay、tmpfs 或網路檔案系統？
- 是否有發布、日誌輪替、備份或批次工作？刪除動作是否受合規保留約束？
- 服務能否短暫降載，是否有健康檢查與回滾窗口？
30 秒回答框架
「我先固定錯誤程序、掛載點和時間窗，同時比較 df -h 與 df -i。若 inode 接近 100%，按目錄和檔案數量定位熱點，檢查容器可寫層、日誌輪替和配額；若 inode 正常，再查區塊空間、保留區塊和刪除但仍開啟的檔案。恢復優先選輪替、壓縮、清理已確認的暫存資料或擴容，並保留證據。最後建立 inode、位元組、目錄檔案數和增長率告警。」
分步深入解答
第一步：確認故障邊界
保存應用程式日誌、核心日誌、失敗路徑和掛載資訊。先確認是單一服務、單一容器，還是整台主機都無法建立檔案。相同錯誤文字可能來自 inode、區塊、配額或唯讀檔案系統。
第二步：並列檢查區塊和 inode
df -hT /
df -iT /
findmnt -T /var/lib/appdf -h 觀察資料區塊，df -i 觀察 inode。兩者都要對應受影響路徑的掛載點讀取。若 inode 接近 100% 而位元組仍有餘量，優先走小檔案定位；若 inode 正常，繼續檢查區塊、配額、唯讀狀態和容器限制。
第三步：按數量定位目錄熱點
先統計目錄項數量而不是讀取全部內容，避免對線上磁碟造成額外 I/O。對候選目錄分層計數，再深入增長最快的分支。find 遍歷應限定路徑、排除其他掛載，並在高峰期設資源預算。
第四步：區分實體檔案與掛載邊界
容器 overlay、bind mount、tmpfs 和日誌卷可能讓主機看到的路徑與程序實際寫入層不同。用程序工作目錄、容器設定和 findmnt -T 交叉確認。不要在主機直接刪除容器層檔案；應透過容器執行時、卷策略或應用清理路徑處理。
第五步：檢查輪替、快取和刪除後仍開啟的檔案
日誌輪替可能只重新命名而未讓程序重新開啟，快取也可能無限產生小檔案。lsof +L1 可找出連結數為零但仍被程序持有的檔案；釋放空間通常要讓擁有者安全關閉或重新開啟。重啟不是預設動作，因為它會丟失現場。
第六步：選擇恢復動作
按風險排序：先停止產生暫存檔的非關鍵工作，再輪替或壓縮已確認日誌，清理有保留策略的快取，最後擴容或遷移。每一步記錄路徑、大小、檔案數、負責人和回滾方式。刪除前驗證檔案不是目前設定、佇列、資料庫或稽核證據。
第七步：驗證恢復和副作用
恢復後再次執行 df -hT、df -iT，做一次真實暫存檔建立、日誌寫入和關鍵請求。確認 inode、錯誤率和延遲恢復；對容器還要驗證重建後檔案數不會立即回升。
第八步：建立長期防線
監控區塊與 inode 使用率、每個掛載點檔案數、目錄增長率、日誌輪替延遲、刪除後開啟檔案數和容器層大小。閾值要配合增長速度與處置時間；把清理、擴容、輪替恢復和驗證步驟寫入可執行運行手冊並定期演練。
設計取捨與邊界
清理與擴容
清理能快速恢復但可能重複發生；擴容提高餘量卻不修復小檔案生成源。先恢復服務，再用增長證據決定改應用、輪替、檔案粒度或擴容。
統計精度與線上成本
全盤 find 精確但昂貴；目錄級計數和抽樣更適合持續監控。事故中逐步縮小範圍，避免 I/O 緊張時遞迴讀取整個檔案系統。
主機與容器
主機指標不能取代容器卷和 overlay 指標。每個寫入層都要有配額、負責人和清理邊界；跨層刪除可能製造不可預測的映像或卷問題。
失敗演練與演進計畫
失敗：只看 df -h
位元組有餘量時仍可能 inode 為零。把 df -i 納入首輪診斷和告警，並按掛載點保存歷史。
失敗：直接 rm -rf 最大目錄
目錄可能包含佇列、證據或目前寫入檔案。先確認擁有者、保留策略、開啟句柄和回滾，再分批清理。
失敗：用重啟代替恢復
重啟可能暫時釋放已刪除檔案，卻丟失現場並掩蓋生成源。優先讓擁有者安全關閉檔案並驗證再次寫入。
常見誤區與追問
誤區：inode 只與檔案大小有關
inode 主要受檔案數量和檔案系統格式影響；大量零位元組或小檔案也會耗盡它。
追問：為什麼刪除檔案後空間沒回來？
程序仍持有檔案描述元時，目錄項已刪除但資料區塊和 inode 仍被佔用；確認持有者並安全重開檔案。
追問：如何區分配額問題？
對照掛載點全域指標與使用者、專案、容器配額，並以同一身分在同一路徑做受控建立測試。
追問：日誌輪替如何驗收？
驗證輪替後程序開啟新檔案、舊檔案句柄關閉、檔案數和 inode 按預算回落，而不是只看到新檔名。
追問：如何防止小檔案風暴？
批次合併、按時間分片、限制快取項目、設定輪替上限，並監控檔案建立速率和目錄項增長。
追問：什麼時候擴容沒有幫助？
當 inode 設計已固定且新磁碟格式仍提供相同密度時，增加位元組容量不能解決 inode 耗盡；應遷移、重建或改變檔案粒度。