符合 POSIX 規範

Google Cloud Managed Lustre 的 POSIX 規範遵循情形有以下例外狀況：

• atime 更新：Lustre 預設會啟用 atime，但基於效能考量，更新可能會延後。也就是說，每次讀取作業後，檔案的存取時間可能不會立即更新。

• flock/lockf：這兩個 API 是指兩個主要的檔案鎖定 API：flock(2) 和 fcntl(2)。

  • flock：這是 BSD 樣式的全檔案諮詢鎖定，並非由 POSIX 定義。Lustre 預設完全支援叢集中的 BSD 樣式 flock 語意。
  • fcntl：這是 POSIX 定義的鎖定 API，支援位元組範圍鎖定。Lustre 實作的 fcntl 鎖定功能幾乎符合 POSIX 標準，可正常運作於大多數應用程式。不過，由於 fcntl 最初是為本機檔案系統設計，因此沒有任何分散式檔案系統 (包括 Lustre) 能 100% 滿足 POSIX 的所有 fcntl 需求。舉例來說，fcntl() 會指定擁有程序結束時必須立即釋放鎖定，但如果用戶端當機，Lustre 鎖定釋放作業可能會延遲。

詳情請參閱 Lustre 常見問題。

因中繼資料遷移而導致的 inode 編號變更

Lustre 檔案系統中的檔案 inode 編號並非不可變更的 ID。

中繼資料重新平衡作業 (例如由 lfs migrate 啟動的作業) 涉及將部分檔案的中繼資料從一個 MDT 遷移至另一個 MDT。直接後果是，這些檔案會獲派新的 inode 編號。

雖然這種行為符合 POSIX 標準，但可能會違反許多常見 Unix/Linux 應用程式和服務的假設，因為這些應用程式和服務會預期檔案的生命週期內都有持續存在的 inode 編號。包括但不限於：

• NFS 和 SMB 前端：這些服務通常會從 inode 編號衍生檔案控制代碼。這項變更可能會導致用戶端發生 Stale file handle 錯誤。

• 封存和備份公用程式：如果工具 (例如 tar) 是依裝置和 inode 編號追蹤檔案，可能會將遷移的檔案視為新檔案，導致增量備份效率不彰。

• 使用 stat() 和儲存 st_ino 的記錄彙整工具、入侵偵測系統和自訂應用程式也可能受到影響。

管理員應瞭解這項行為，以及手動重新平衡中繼資料前，這項行為可能對應用程式造成的影響。

緩解策略

中繼資料重新平衡應視為預定的中斷性維護事件。

1. 排定維護期間。向所有使用者和應用程式擁有者說明預計的服務中斷時間。請盡量不要在實際運作的生產系統上執行大規模的 lfs migrate 作業。

2. 如有需要，請在遷移後卸載並重新掛接檔案系統。

3. 遷移後，部分應用程式可能需要清除或重新啟動。