我有一个应用程序，要求 inode 在安装、重新启动等过程中保持不变。
使用mount -t cifs -o serverino，它应该这样做（在服务器支持的情况下）。但是，当我挂载时，一些随机的文件和目录集将具有客户端生成的顺序 ID < 2^32。
我尝试过多种组合，包括-o nounix -o serverino -o mfsymlinks -o noacls、 和许多其他组合，但似乎都没有改变事物的随机性。
每当它返回 > 2^32 inode 时，据我在多次挂载尝试中看到的（未彻底确认），对于给定的文件/目录来说，它似乎是一致的，但是很大比例但随机的文件集很小在列表输出中单调递增的 inode 编号。
服务器是Windows2012R2。客户端是具有最新内核的 CentOS 和 Ubuntu Linux。一个是 3.10.0，另一个是 4.4.0
是否可以在客户端或服务器端设置任何内容，以便在像这样安装时将 UniqueId 或 FileID 作为 inode 返回给客户端？
（在版本 1、2.1 和 3.0 协议中尝试过）
答案1
根据文档mount.cifs(8)，传递该serverino选项应该启用服务器端 inode 编号，但前提是服务器上有可用的“CIFS UNIX 扩展”（请参阅“INODE NUMBERS”部分）：
当启用 Unix 扩展时，我们使用服务器响应 POSIX 调用提供的实际 inode 号作为 inode 号。
当禁用 Unix 扩展并
serverino启用“”挂载选项时，无法获取服务器 inode 号。客户端通常将服务器分配的“UniqueID”映射到索引节点号。请注意，UniqueID 的值与服务器 inode 号不同。 UniqueID 值在整个服务器范围内是唯一的，并且通常大于 2 的 32 次方。该值通常会使未使用 LFS（大文件支持）编译的程序触发 glibc EOVERFLOW 错误，因为这不适合在目标结构领域。强烈建议您在编译程序时使用 LFS 支持（即使用
-D_FILE_OFFSET_BITS=64）来防止出现此问题。您还可以使用“noserverino”挂载选项在客户端上生成小于2的32次方的inode编号。但您可能无法正确检测硬链接。
并没有直接表明在文档中CONFIG_CIFS_POSIX，但您可能需要在内核中启用“CIFS POSIX Extensions”（内核选项）。
由于 Windows Server 2012 没有这些扩展，您可能需要改为启用 NFS 服务器功能并使用它。
顺便说一句，cifs这并不是唯一出现这种情况的文件系统：/sys、/dev和/proc文件系统也可能表现出这种行为。