Linux檔案系統結構與故障排查

當你租用一台伺服器租用並打開 Shell 時，首先面對的就是 Linux 檔案系統。它不僅僅是一個數據夾階層——它是數據完整性、效能和安全的基石。無論你管理的是伺服器託管，理解Linux檔案系統在系統呼叫層面的原理，能幫助你診斷為什麼刪除檔案後磁碟仍然顯示已滿，或者為什麼 Web 伺服器返回 403 錯誤。本指南摒棄華而不實，直擊 inode、目錄結構以及在伺服器租用環境中經過實戰檢驗的故障排查方法。

1. 根目錄階層：伺服器租用中需要關注的目錄

檔案系統階層標準（FHS）定義了所有內容的存放位置。對於伺服器租用，某些目錄需要特別關注，因為它們可能會被填滿或成為安全漏洞。

• / – 根目錄。如果根目錄滿了，系統將變得不穩定。務必留意。
• /home – 存放使用者數據（例如網站）的地方。在共享伺服器租用中，這通常是最大的分割區。如果沒有隔離，一個使用者就可能填滿整個磁碟。
• /var – 日誌檔案、郵件佇列和暫存執行時期數據。在繁忙的伺服器租用中，/var/log 每天可能增長數 GB。攻擊者也喜歡在此寫入暴力破解日誌。
• /tmp – 全域可寫目錄。建議使用 noexec 和 nosuid 選項掛載，以防止惡意指令碼執行。
• /etc – 設定檔。通常不會佔用太多空間，但錯誤的權限可能導致整個伺服器癱瘓。

伺服器租用提供商通常會對 /home 和 /var 進行獨立分割區，以防止日誌氾濫導致作業系統崩潰。使用 df -h 可以檢視它們的掛載情況。

2. Inode 與區塊：原子單元

Linux 中的檔案由元數據（inode）和數據區塊組成。inode 儲存除檔名和內容之外的所有資訊：權限、擁有者、時間戳以及指向數據區塊的指標 。

每個檔案系統在格式化時會建立固定數量的 inode。如果你有數百萬個小檔案（比如 session 檔案或郵件佇列），即使 df -h 顯示還有剩餘空間，inode 也可能耗盡。這是伺服器租用中常見的陷阱。

# 檢查 inode 使用情況
df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1       3276800 3276800 0     100%   /

當 IUse% 達到 100% 時，核心將拒絕建立新檔案或目錄——即使是空檔案也不行。解決方法：找到包含大量小檔案的目錄，要麼刪除它們，要麼重新格式化並設定更多的 inode。

查詢高 inode 佔用目錄：

1. 進入可疑分割區（例如 /var）。
2. 執行 find . -xdev -type f | cut -d "/" -f 2 | uniq -c | sort -n。
3. 定位到罪魁禍首（通常是 /var/spool 或 /var/lib/php/sessions）。

3. 權限與擁有者：安全層

在多租戶伺服器租用中，Linux 權限是第一道防線。每個檔案都有擁有者、群組以及三組權限：讀（4）、寫（2）、執行（1）。設定錯誤會導致 403 錯誤，甚至數據外洩。

• 符號表示法： chmod u+x script.sh 為擁有者新增執行權限。
• 八進位表示法： chmod 644 file 賦予 rw-r–r– 權限。

特殊權限位在伺服器租用中至關重要：

• 目錄上的 Setgid： chmod g+s /home/project 確保新檔案繼承群組屬性，適用於團隊協作。
• /tmp 上的黏著位： chmod +t /tmp 防止使用者刪除彼此的暫存檔案。

真實伺服器租用場景： 透過 FTP 上傳 PHP 指令碼，但存取時出現 500 錯誤。檢查檔案擁有者。如果 Web 伺服器以 www-data 身份執行，而檔案歸屬於 user:user，則需要群組讀取權限。通常，將權限設定為 644 並確保檔案所在的群組包含 www-data 即可解決問題 。

4. 磁碟滿了？這裡有排查方法

磁碟佔滿是伺服器租用中最常見的故障原因。但有時 df 顯示 100%，而 du 彙總卻遠遠小於此值。這是典型的「已刪除檔案仍被程序佔用」場景 。

1. 檢查磁碟使用情況： df -h 確定哪個分割區滿了。
2. 查詢大目錄： du -sh /* 2>/dev/null | sort -h。深入排查：du -sh /var/* | sort -h。
3. 定位大於 100M 的檔案： find / -type f -size +100M -exec ls -lh {} \;
4. 如果 df 顯示已滿但 du 不一致： 某個程序仍在佔用已刪除的檔案。執行 lsof | grep deleted 可檢視這些檔案。重啟相關服務（例如 systemctl restart httpd）即可釋放空間 。

在伺服器租用環境中，日誌檔案是首要懷疑對象。積極使用 logrotate，並考慮遠端日誌記錄，以避免 /var 被填滿。

5. 檔案系統檢查與復原

異常關機（斷電、核心崩潰）可能導致檔案系統損毀。下次掛載時可能會強制執行 fsck，但有時需要手動干預。對於 ext4，務必在卸載狀態下執行 fsck 。

針對根檔案系統的操作步驟：

• 進入救援模式（大多數伺服器租用提供商提供復原 Shell）。
• 執行 fsck -fy /dev/sda1（替換為你的分割區）。-f 強制檢查，即使標記為乾淨；-y 對所有修復回答「是」 。

對於 LVM 磁碟區，可以建立快照並在原始磁碟區掛載的情況下檢查快照 。這屬於進階操作，但能在檢查期間保持服務線上。

# LVM 快照 + fsck 範例
lvcreate -s -n root_snap -L 1G /dev/vg/root
fsck -fy /dev/vg/root_snap
lvremove -f /dev/vg/root_snap

6. 針對伺服器租用負載的效能調校

伺服器租用通常處理混合負載：大量小檔案（HTML、PHP）和少量大檔案（日誌、備份）。檔案系統的選擇與掛載選項至關重要 。

• 檔案系統類型： ext4 是穩妥的通用選擇。XFS 在處理大檔案和高併發時表現出色（適用於郵件伺服器或大型數據庫） 。
• 掛載選項： 在 /etc/fstab 中新增 noatime 可消除每次讀取時的寫入操作，在 HDD 和 SSD 上都能提升效能 。
• I/O 排程器： 對於 SSD，使用 none（或 noop）。對於機械硬碟，deadline 通常能在負載下提供更低的延遲。修改方式：echo deadline > /sys/block/sda/queue/scheduler。
• Swappiness： sysctl vm.swappiness=10 告訴核心僅在記憶體極度緊張時進行交換，從而減少磁碟 I/O 。

不要盲目調校；使用 iostat -x 1 監控 await 和 util%。如果 SSD 上的 await 超過 20ms，可能存在控制器問題，或者需要調整佇列深度。

7. 特殊場景：唯讀檔案系統

有時檔案系統在發生 I/O 錯誤時會自動重新掛載為唯讀。這是一種防止損毀的安全機制。如果遇到「唯讀檔案系統」錯誤，請檢查 dmesg 是否有磁碟故障資訊。這通常是硬體故障的前兆。

立即操作：嘗試重新掛載為讀寫以提取數據：mount -o remount,rw /掛載點。但如果底層裝置存在錯誤，此操作可能會失敗。此時應更換磁碟並從備份中復原。

8. 自動化與監控

主動監控勝過被動救火。設定 cron 任務每日檢查磁碟和 inode 使用情況：

#!/bin/bash
# 儲存為 /etc/cron.daily/diskcheck
df -h | awk 'int($5) > 90 {print "磁碟即將佔滿: " $0}' | mail -s "磁碟警示" admin@example.com
df -i | awk 'int($5) > 90 {print "inode即將佔滿: " $0}' | mail -s "inode警示" admin@example.com

同時監控被刪除但仍被打開的檔案數量。突然的峰值可能意味著有 bug 的程序洩漏了檔案描述子。

結論

Linux 檔案系統是精心設計的工程傑作，但需要正確對待。從 inode 表到權限位，每一個細節在伺服器租用環境中都可能成為瓶頸或安全漏洞。掌握上述指令和概念，能將檔案系統故障排查從玄學轉變為系統化流程。密切關注Linux檔案系統的健康狀況，你的伺服器管理將不再被動。