科技 · 實用指南
Linux 顯示「裝置沒有空間」，但 df 明明有餘量？先查確切失敗路徑
ENOSPC 不代表你查看的檔案系統已滿。先把失敗路徑映射到真實掛載點與儲存後端，再依序檢查區塊、inode、已刪除但仍開啟的檔案、配額、overlay 與檔案系統限制。
「No space left on device」只是某次失敗操作傳回的錯誤，不能證明裸跑 df 時看到的檔案系統就是失敗目標，也不能證明唯一短缺的是位元組空間。
先保存確切失敗路徑，確認它所在的掛載點、檔案系統類型與儲存邊界。在同一路徑檢查區塊與 inode，再依證據進入已刪除但仍開啟、隱藏掛載、配額、容器層或檔案系統分配分支。
清理前先保存失敗路徑
保存完整錯誤、命令、時間與目標路徑。若應用程式隱藏路徑，開啟正常診斷日誌或只重現一次；不要先刪檔或重啟。
記錄寫入發生在主機、容器、bind mount、CI workspace 還是其他儲存服務；跨邊界後相同目錄名可能指向不同後端。
讓 df 查詢那條確切路徑
對失敗路徑或現有父目錄執行 df，記錄 Filesystem、Type、Size、Avail 與 Mounted on；再對同一路徑查 inode。
若路徑尚不存在，就往上找最近的現有父目錄並保存 mount view，避免把獨立 /var、bind mount、overlay 或網路檔案系統當成根分割區。
區分區塊與 inode 容量
區塊不足時，只在該檔案系統內找大型用量，刪除前確認保留政策與擁有者；沒有明確需求時不要跨掛載掃描。
inode 不足但區塊仍有餘量時，找出產生大量小檔案的目錄。增加位元組容量不一定會在所有檔案系統增加 inode。
解釋 df 與 du 差異而不丟證據
若 df 的分配量高於目錄掃描，檢查仍被程序開啟的已刪除檔案；先記錄 PID、服務、fd 與大小，再決定是否安全重啟、reload 或 truncate。
也要檢查掛載點下是否藏有較早寫入的檔案。生產環境卸載可能中斷服務，應使用維護時段或安全 namespace。
檢查配額、容器與檔案系統限制
區塊與 inode 都健康時，檢查實際 writer 的 user、group 或 project quota 與 reserved allocation；容器先保存 storage root、driver、writable layer 與宿主後端。
再用檔案系統專用工具檢查 metadata、snapshot、copy-on-write reservation 或 pool 容量，不能把 ext4 方法直接套到其他系統。
只修已證實分支並重測原寫入
選擇最小可逆動作：依政策清理、輪替日誌、釋放已確認的 open file、擴充正確 volume、調整有依據的 quota 或依文件遷移 container storage。
只重試一次原寫入，再在相同目標路徑確認容量、inode 或 quota 餘量，並持續觀察是否真的穩定。
