Linux 磁碟空間已滿：檢查掛載點、inode 及可清理檔案

Linux 磁碟空間已滿、報空間不足時，先找出拒絕寫入的檔案系統和掛載點，再比較容量與 inode。只在同一檔案系統內用 du -x -d 1 縮小目錄範圍（-d 在 Linux 的 GNU du 和 macOS 的 BSD du 中都表示深度），檢查 journal、套件快取和已刪除但仍由程序開啟的檔案。先釋放少量可復原空間，在原掛載點驗證，再計劃深入清理。

關鍵要點

• 根檔案系統已滿、home 已滿、inode 用盡和預期掛載缺失，需要不同修復。
• df 報告檔案系統用量，du 統計可存取目錄項目；兩者可以合理地不同。［1］［2］
• 掃描應限制在一個檔案系統，避免其他掛載點干擾。
• 不要因為檔案很大就直接刪除 /usr、/var/lib 或未知應用程式資料。

通用方法見裝置故障排查指南。如套件操作也失敗，先復原工作空間，再使用 APT 錯誤指南。

Linux 磁碟空間已滿時，是哪個檔案系統滿了？

保留失敗的路徑和錯誤訊息，直接就該路徑查詢 df：

df -h /path/that/failed
df -i /path/that/failed
findmnt -T /path/that/failed

df -h 顯示容納該路徑的檔案系統已用和可用容量，df -i 顯示 inode 用量；df 手冊定義這些檔案系統級統計以及易讀格式選項。findmnt -T 可確認路徑背後的掛載點。

大量小檔案可能耗盡 inode，即使仍有容量。另一個磁碟有空間，也不能幫助已滿的根或獨立 /var。如預期資料磁碟沒有掛載，應用程式可能把資料寫入根檔案系統的底層目錄；先安全復原掛載，再判斷檔案歸屬。

保留空間和配額政策應與系統擁有人確認，不要以為表面的百分比就是全部。在生產或加密系統上更改儲存前，先保留復原存取。

如何安全尋找 Linux 最大目錄？

從故障掛載點開始並限制在該檔案系統。根目錄例子：

sudo du -x -h --max-depth=1 / 2>/dev/null

-x 跳過其他檔案系統上的目錄，--max-depth=1 限制第一輪深度。將結果排序或逐項查看，然後只對一個你認得的大目錄重複一次，例如 /var 或某個用戶目錄。不要一開始無界掃描所有磁碟、網絡共享、container 掛載和備份卷。

du 統計的是可存取的目錄內容。不要因為某個目錄排名第一就刪除；先確認它的擁有者和用途。資料庫、虛擬機映像、container 儲存、備份、郵箱或相片庫都需要專屬保留和停機流程。

大量用戶資料應優先把已核實的檔案移到另一個有備份的檔案系統，或經所屬帳戶刪除可復原的下載。移動資料前，先確認目的地位於不同的檔案系統，而且空間足夠。

為何 df 和 du 不一致？

常見原因包括：

• 目錄項目已刪除，但程序仍開啟該檔案；
• 檔案系統中繼資料、snapshot、保留區塊或寫入時複製行為；
• 量度目錄時沒有權限讀取部分子項目；
• 資料被另一個掛載的檔案系統覆蓋；
• du 和 df 在不同時間量度，期間仍有寫入。

已安裝 lsof 時可檢查：

sudo lsof +L1

如大檔案仍被持有，應按服務文件安排受控重新啟動或 reload。不要截短未知 descriptor，也不要在沒有維護計劃時停止關鍵服務。最後一個程序關閉檔案後，空間通常才會釋放。

如何檢查 systemd journal 和快取？

先檢查 systemd journal 的磁碟用量：

journalctl --disk-usage

journalctl 手冊記錄了佔用檢查和 vacuum：它按大小或時間界線移除最舊 archived journal，active journal 不會直接由 vacuum 移除；與日誌輪替有意識地配合使用時，效果通常最明顯。［3］確認 archived journal 是主要可回收項後，才設定符合保留要求的上限，例如：

sudo journalctl --vacuum-size=500M

500M 只是例子，不是通用政策。保留理解空間增長所需的近期日誌，並按保留、事故應變和合規需要選擇上限。

APT 快取亦要先量度：

du -sh /var/cache/apt/archives
sudo apt-get clean

apt-get clean 移除已下載套件快取，不會解除安裝軟件。只在快取位於受影響檔案系統、而套件資料庫仍有工作空間時使用。其他應用程式應使用自己的清理工具，不能泛化為手動刪除資料目錄。

如何在不遺失證據下騰出應急空間？

檔案系統接近滿載並妨礙正常工具運作時，首要目標是騰出一小塊可量度的工作空間，而不是盡量刪除最多資料。如運維上安全，先減慢或暫停已確認的寫入者。然後只選一個已確認擁有者、位於受影響掛載點且可以復原的類別，例如重複輸出或已下載封存檔。修改前記錄路徑、大小、擁有者和移除理由。

第一次清理前回答四個問題：

• 對象是否確實位於 df -h /path/that/failed 報告的檔案系統？
• 它能否重新產生、是否已有備份，或是否受批准的保留政策規限？
• 應用程式是否仍在寫入，或是否要求它留在原本位置？
• 此操作預計釋放多少容量或 inode，之後用甚麼方法驗證？

只釋放一個有界類別，隨即對同一個失敗路徑重跑 df -h 和 df -i。如沒有出現預期空間，應停止並檢查已刪除但仍開啟的檔案、缺少掛載點、權限、快照或持續寫入，不要繼續刪除第二個無關類別。這樣既保留原始增長的證據，亦避免把應急清理變成未經審查的保留政策。

在共享或生產機器上，重新啟動程序或 vacuum 日誌前要記錄服務擁有者與維護決定。應急空間只需足以恢復受控運作和診斷；長期保留、配額、掛載修正或容量擴展應作獨立跟進，並配置自己的回復與監察。

應先釋放甚麼？

按以下次序處理：

步驟 1：減慢已確認的寫入者

在運維安全的情況暫停持續產生資料的工作。

步驟 2：釋放可復原的用戶資料

移動或刪除已確認可復原的下載、輸出和重複暫存檔案。

步驟 3：使用套件快取擁有者工具

經擁有者工具清理已確認的套件快取。

步驟 4：限定 archived journal 清理界線

先確認保留需要，再按明確的大小或時間界線對 archived journal 執行 vacuum。

步驟 5：安全關閉已刪除但仍開啟的檔案

透過受控服務重新啟動處理這些檔案。

步驟 6：執行應用程式專屬保留政策

資料庫、container、備份或郵件只可按應用程式專屬程序處理。

不要直接刪除 /usr、/var/lib 下的檔案，不要用寬泛 pattern 清空目錄，也不要截短未知日誌。這些操作可破壞套件、資料庫、container 或審計證據，而釋放的空間亦可能比預期少。

如何驗證復原？

對同一路徑重複量度：

df -h /path/that/failed
df -i /path/that/failed

同時確認可用容量和 inode，再重試代表性寫入或原服務健康檢查。記錄釋放量和增長類別。如失控日誌、失敗備份、無界快取或缺失掛載很快再次填滿，清理仍未完成。

穩定後應使用應用程式支援的保留設定、監察和警報界線，並為套件升級、日誌、資料庫交易和復原預留空間，而不只是容納目前的穩定資料量。

總結

先定位故障檔案系統，再比較容量和 inode，以同檔案系統 du 縮小擁有者。結合 journal、快取、掛載和已刪除但仍開啟檔案，解釋 df 與 du 的差異。只經擁有者工具回收已識別、可復原的資料，最後在同一掛載點驗證並防止再次發生。

常見問題

df -h 有空間，為何仍報不足？

可能是 inode 用盡、quota 限制，或失敗路徑屬另一掛載點。對該路徑檢查 df -i 和 findmnt -T。

為何 du 比 df 小？

已刪除但仍開啟檔案、中繼資料、保留空間、snapshot、被掛載覆蓋內容或不可讀目錄均可造成差異。

可手動刪除日誌嗎？

不可作通用做法。先確認擁有者和保留政策；systemd journal 應使用有界線的 archived vacuum。

du -x 有甚麼作用？

它會跳過位於其他檔案系統的目錄，令調查只針對已滿掛載點，不把無關磁碟或網絡共享的用量計算在內。

du -d 深度參數在 Linux 和 macOS 上是甚麼意思？

-d N 只顯示位於指定路徑下 N 層以內的目錄。在 Linux 的 GNU du 中，它是 --max-depth=N 的簡寫［2］，因此 du -x -h -d 1 / 與上文指令一樣只做有界的第一輪掃描。macOS 內置的 BSD 版 du 同樣接受 -d、-x 和 -h，但不支援 --max-depth 這類 GNU 長選項；可在 Mac 上執行 man du 確認目前版本。

apt-get clean 會解除安裝軟件嗎？

不會。它只會移除 APT 已下載的套件封存檔，已安裝的套件仍然保留；日後需要這些封存檔時可能要重新下載。

已刪除但仍開啟的檔案如何釋放？

最後一個持有程序必須關閉該檔案，通常按服務文件安排受控重新啟動或重新載入。再次刪除路徑不會釋放仍被開啟的檔案空間。

可立即刪除最大目錄嗎？

不可。先確認擁有者、用途、備份狀態和支援的保留方式；大型資料庫或應用程式目錄不是普通可棄檔案。

---

免責聲明：儲存配置、檔案系統、quota、snapshot 和服務流程各不相同。重要系統應保存備份、復原存取和應用程式專屬文件。

來源：

1. Ubuntu Manpage Repository — df(1) — https://manpages.ubuntu.com/manpages/noble/man1/df.1.html
2. Ubuntu Manpage Repository — du(1) — https://manpages.ubuntu.com/manpages/noble/man1/du.1.html
3. Ubuntu Manpage Repository — journalctl(1) — https://manpages.ubuntu.com/manpages/noble/man1/journalctl.1.html

Sources checked 2026 年 10 月 4 日。

---

延伸閱讀：

• 裝置故障排查指南
• 修復 apt update 錯誤和損壞的相依套件
• APT、DEB、Snap、Flatpak 與 AppImage 比較
• 安裝雙系統前的備份與分割區檢查