引言

“Everything is a file（一切皆文件）”是UNIX世界里的名言，也是UNIX系統的設計思想之一。在其之后演變出眾多UNIX、Linux，如開源的FreeBSD、OpenBSD、GNU/Linux或商業的AIX、HP-UX、Solaris等均繼承了該思想。不論是普通文件、目錄、字符設備、塊設備、socket套接字、網絡設備等，對操作系統來說都是文件。雖然類型不同，但操作系統都提供了一套統一的接口，即文件系統來對上述各種文件統一管理。本文講述了G行文件系統使用中遇到的一些有趣問題和解決辦法，供大家參考。

1、文件系統的基本功能

文件系統是操作系統的重要組成部分，定義了把文件存儲于硬盤時的數據結構及管理方式。硬盤是由很多扇區組成，為了訪問硬盤中的數據，就必須在文件和扇區之間建立聯系，比如需要知道文件從哪個扇區開始、一共占多少個扇區、文件有什么屬性……這就是文件系統要做的事情。

一個操作系統通常會建立多個文件系統，每個文件系統都有獨立和完整的結構，當一個文件系統出現問題不會影響到其他文件系統。通過文件系統還可以實現配額管理，限制用戶的存儲空間容量，防止用戶無限制地使用存儲空間。

 一般來說，文件系統是和操作系統緊密結合在一起的，不同類型的操作系統默認使用不同的文件系統，比如AIX的jfs2文件系統、HP-UX的vxfs文件系統、Linux的ext4文件系統等。

2、文件系統和LVM

文件系統通常建立在LVM（Logical Volume Manager）之上。基于LVM的管理功能，將硬盤或硬盤分區組合起來，創建一個邏輯層給文件系統使用，實現了靈活、方便、動態地管理各種存儲設備。各類UNIX/Linux在LVM管理上大同小異，如下圖所示：

圖片

硬盤（或使用SCSI等協議連接的外置存儲）在LVM中被標記為物理卷（PV，Physical Volume），多個PV組成一個卷組（VG，Volume Group），然后，在VG中劃分出多個邏輯卷（LV，Volume Group），最后將LV格式化成文件系統（FS，File System）供用戶使用。這樣，一個文件系統的大小就突破了物理硬盤空間連續性的限制，也可以跨多個硬盤，提供更大的存儲空間。LVM也可用于提升I/O性能，通過對LV邏輯卷設置條帶化，使I/O落在多個PV物理卷上。

3、文件系統使用中遇到的典型問題

文件系統雖然有上述各種優點，但是實際使用中也遇到過形形色色的問題，接下來我們分享幾個有代表性的文件系統問題。

案例1:某服務器在編譯Tuxedo ubb配置文件時，編譯報錯，并且沒有日志生成。

圖片

從官方錯誤編碼解釋分析：編譯文件所在的目錄中，存在目錄名過長（大于78個字符）或目錄結構權限錯誤。

圖片

但檢查確認該ubb所在的目錄中，不存在過長的目錄名。嘗試將權限都改成了777，編譯仍然報錯。

圖片

對編譯命令進行truss跟蹤，發現編譯命令在檢查當前路徑的權限時報EACCES錯。EACCES錯誤的說明是“Search permission is denied on a component of the path prefix.”，Search permission也就是x（執行）位的權限。

圖片

根據報錯提示，執行檢查命令，也驗證了Permission denied錯誤。通過AIX官方文檔資料確認，在AIX操作系統中，所有的jfs/jfs2文件系統都有兩套權限：文件系統權限和文件系統掛載點目錄權限。用戶要對文件系統和掛載點目錄都有r和x（searchable）的權限才能正常使用。卸載文件系統后，對掛載點目錄賦權755，重新掛載文件系統，編譯順利通過。

圖片

案例 2:某個批量任務每天自動創建 24 個目錄(每小時 1個)。某天運行該任務時突然報錯，顯示不能創建目錄。

圖片

按照錯誤提示，手工檢查當前文件系統空間和 inode 使用率都不高。該批量任務報錯前創建了 9 個目錄，手工嘗試創建第 10個目錄也失敗了，報錯信息和批量任務的報錯信息一致。

圖片

進一步排查發現批量任務腳本中對歷史文件打包備份后僅是清理了文件而未刪除目錄，導致目錄累計越來越多。當前目錄下的子目錄一共 32767 個，懷疑是一個目錄下的子目錄數量達到了上限。對這些歷史子目錄進行清理后，新子目錄創建成功。

圖片

我們對 AIX、HP-UX、Linux 等操作系統進行了測試，結果表明 AIX 和 HP-UX 的文件系統的目錄有 32768 個子目錄的限制，Linux 內核版本小于等于 3.0.101 是有 32000 子目錄限制。于是，我們將一個目錄下的子目錄數量統計加入巡檢和監控，當發現子目錄數量接近 30000 時會自動通知管理員進行清理。

案例 3:一個業務系統做壓力穩定性測試時，發現四臺應用服務器中的一臺交易響應變慢。查看這臺服務器上的應用日志，發現有接近 15 秒的“斷檔”，沒有記錄。而同一時段的其他 3 臺應用服務器的日志記錄均是連貫的。

圖片

查看這臺故障服務器的性能數據，發現故障時段 vxfsd 進程竟然占用了 8 顆 CPU。應用日志所在的目錄就是一個單獨的 vxfs文件系統，vxfsd 又是 vxfs 文件系統的主進程，因此定位是 vxfs故障導致應用日志無法寫入。

圖片

進一步排查發現這臺服務器應用日志文件系統的 lastid 計數器值遠遠小于其他 3 臺服務器的數值。

圖片

圖片

查看 vxfs 的官方文檔確認:lastid 計數器最大值是 2 的30 次方，約等于 10 億 7 千萬。超過最大值后，vxfsd 進程就會對 vxfs 文件系統元數據(包括 lastid)自動重置，重置耗時 15秒，期間會影響 I/O。

了解 vxfs 這個特性后，我們部署了巡檢和監控:當一個 vxfs文件系統的 lasitd 達到 8 億時通知管理員。管理員選擇業務低峰時段主動對 lastid 這一元數據進行手工重置，避免在業務高峰時段因為 lastid 自動重置影響系統性能。

4、展望

隨著硬件技術的發展，文件系統技術也在不斷創新。尤其是SSD 閃存盤的普及，需要文件系統提供與之相適應的文件管理方式，如 BTRFS 的 COW(Copy On Write)方式，避免頻繁擦寫 SSD，提升了 I/O 性能也延長了 SSD 的使用壽命。再有，ZFS 等新一代文件系統自身就具備了對硬盤的條帶化和鏡像能力，已經不需要LVM 的支持了。但是，無論文件系統功能如何演進，它的基本原理沒有改變，值得我們深入探究。