我有 3 台计算机 A、B 和 C，我在它们上执行相同的操作系统和软件安装。对于 A 上的任何特定文件，我是否可以期望 B 和 C 上的同一文件的该文件实例具有相同的 inode 号？
我们的入侵检测系统是通过从 A 获取初始文件系统映像，然后使用相同的文件系统映像对 A、B 和 C 进行未来比较来设置的。我是该程序的新手，但似乎这已经起作用了在过去。
我不知道 inode 编号排序是如何工作的，所以我猜测它只是从 1 开始并对每个文件进行计数，或者类似的东西。如果是这样的话，这可能就是为什么文件 inode 号在过去甚至在我们的计算机上都是一致的 - 相同的文件是以相同的顺序创建的。尽管我不确定我们是否可以始终依靠这一点。
但是，现在我收到了一些文件已更改的通知，对于第一个文件，我正在查看的只是已更改的文件索引节点号。我认为有人在计算机上重新安装了操作系统和软件并发出了通知。
在不同计算机上安装相同的操作系统/软件（或在同一台计算机上顺序重新安装）时，文件索引节点号是否可以被认为是相同的？
如果我要从 A、B 或 C 获取新的文件系统映像，我是否可以期望它能够解决我的“问题”（甚至不确定这是否是一个问题）？
我通常一次只能访问 1 或 2 台计算机，所以我现在无法检查 A 或 C，而且我不知道他们的报告会是什么样子。我只知道B计算机上至少有1个文件的inode编号不是预期的。
在本例中，操作系统是 QNX 6。对于文件系统类型，mount告诉我 /dev/hd 文件是“on / type qnx4”...那么文件系统类型 qnx4？我猜 qnx 有它自己的文件系统类型？我没有意识到这一点。或者也许这并不准确。计算机上似乎不存在用于检查文件系统类型的其他命令。
更新: 显然我误会了一些事情。尽管我们关于文件系统原始状态的参考数据确实包括文件的索引节点号，并且我可以选择将其包含在测试中，但我不应该在问题中描述的检查中包含索引节点数据，并且“过去行得通”就是因为这个。所以我实际上并不需要我在这里要求的东西，对此感到抱歉。不过，我将保留这个问题，因为我仍然觉得它很有趣，并且评论中已经开始了部分答案。
答案1
[...]并且我在它们上执行相同的操作系统和软件安装。
对于 A 上的任何特定文件，我是否可以期望 B 和 C 上的同一文件的该文件实例具有相同的 inode 号？
不会，因为 I/O 并行运行，并且 I/O 操作的顺序不确定并受硬件操作的影响。操作系统分配 inode 号，如果某些操作在系统 A 和 B 上以不同的顺序运行，则操作系统可以为“相同”文件分配不同的 inode 号。
类似的工件是，/dev/即使在同一系统上，也不能保证重新启动后分配的一致性：/dev/sdb现在的内容可能是/dev/sda上次启动时的内容。
如果我要从 A、B 或 C 获取新的文件系统映像，我是否可以期望它能够解决我的“问题”（甚至不确定这是否是一个问题）？
这不是问题（除非你把它变成一个问题），是的，如果你复制整个文件系统映像，它们将具有相同的索引节点号。
尽管我们关于文件系统原始状态的参考数据确实包括文件的索引节点号，并且我可以选择将其包含在测试中，但我不应该在问题中描述的检查中包含索引节点数据，
确切地。答案是“不，你不能依赖它，因此你不应该测试它，因为那样它就会成为一个问题。”