Isilon： 了解 Isilon 文件句柄

一般而言，文件句柄是在 NFS 服务器上构建的，并且可能因平台而异。在 OneFS 中，在创建文件时创建逻辑输入 （LIN） 时，将创建文件句柄。文件句柄包含相关文件/目录的文件系统 ID （FSID）、导出 ID 和 LIN。OneFS 文件句柄为 64 位，因此在理论上不受限制（可能的并发文件句柄总数 = 18 万亿 * 10^19）。理论上，在最大使用量下，可能需要 10 亿年才能耗尽 Isilon 群集上的可用逻辑信息节点。

由于 OneFS 不回收逻辑索引节点，因此 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，因此可能会引发过时的文件句柄错误。

过时的文件句柄可能是由于客户端缓存问题导致的，或者文件未锁定，并且已打开供两个或更多并发用户编辑。需要文件锁定才能修复过时的文件句柄。