Isilon： 瞭解 Isilon 檔案控制代碼

通常，檔句柄是在 NFS 伺服器上構建的，並且可能因平臺而異。在 OneFS 中，在建立檔案時建立邏輯作業系統 （LIN） 時，會建立檔案控制代碼。檔案控制碼包含相關檔案/目錄的檔案系統 ID （FSID）、匯出 ID 和 LIN。OneFS 檔案句柄為 64 位元，因此理論上不受限制 （可能的總並行檔案句柄 = 18 quintillion * 10^19）。在最大使用率下，理論上可能需要 10 億年才能耗盡 Isilon 叢集上的可用邏輯 inode。

由於 OneFS 不會回收邏輯 inode，因此可以預期 LIN 會與其對應的檔案句柄建立關聯。

lincount 工作可用來尋找叢集目前的 LIN 計數：

# isi job start lincount
# isi job reports view <JobID> 


Example:
------------

ps9500x3-2# isi job start lincount
Started job [5983]


ps9500x3-2# isi job reports view 5983
LinCount[5983] phase 1 (2025-11-25T20:40:04)
--------------------------------------------
LINs traversed  28865  
SINs traversed  0
JE/Error Count  0
JE/Time elapsed 7 seconds
JE/Time working 9 seconds

LinCount[5983] Job Summary
--------------------------
Final Job State  Succeeded
Phase Executed   1

由於 LIN 是 OneFS 檔案控制碼的一部分，因此可以從檔案控制碼解壓縮 LIN。請參考以下連結以瞭解此程序。

如何從檔案句柄

取得 LIN由於此限制，部分作業系統和舊版應用程式無法接受 64 位檔案控制碼，也無法與 Isilon 叢集互動。
若要解決此限制，OneFS 可將 32 位元檔案 ID 傳回給用戶端，但此功能確實需要付出代價且需要注意。
如果超過 40 億個檔，或者如果創建和刪除的檔周轉量足夠大，則存在 LIN 包裝的可能性（模 32 位）。這可能會導致多個 LIN 指向同一檔句柄。從數學上講，這種情況極不可能發生，但如果滿足上述條件，確實存在嚴重數據丟失的可能性。實現 32 位檔 ID 時必須謹慎行事。在撰寫本文時，尚未在 Isilon 叢集上發現此問題發生。

如何在 NFS

上實現使用 32 位檔案 ID有時，您可能會看到過時的檔句柄問題。過時的檔句柄是不再對應於活動 FSID 的檔句柄。FSID 以世代 ID （GENID） 為基礎，類似於檔案的「版本編號」。寫入並非基於最新的 GENID，因此可能會引發過時的檔句柄錯誤。

過時的檔句柄可能是由用戶端緩存問題導致的，或者檔未鎖定，並且由兩個或多個併發用戶打開以供編輯。需要檔案鎖定才能補救過時的檔案控制代碼。