linux - 重启后的 inode 编号

Question

在重新启动、重新挂载或什至在它被所有进程关闭然后再次打开之后，inode 号是否保证(例如通过标准)相同？例如。它可以在打开文件时自动生成而不是存储在文件系统中吗？应用程序可以依赖它吗？文件系统实现是否需要保证特定的语义？

Answer 1

inode 不是每个文件系统的通用概念。 Ext 文件系统和 Linux VFS 将 inode 视为存储文件信息的数据结构。但是，例如，FAT32 或 NTFS 不知道什么是 inode，因为它们根本不使用该概念。

说到这里，我将尝试回答您的问题:

Is the inode number guaranteed (e.g. by a standard) to be the same after a reboot, a remount or even after it was closed by all processes and then opened again?

取决于，如果文件系统是 Ext 类型，那么 inode 编号存储在 struct inode 内的 i_ino 文件中，写入磁盘，所以是的，在这种情况下，如果文件相同(不是其他同名文件)，则 inode 编号保证是一样的。

否则，如果文件系统不是Ext，则inode 编号由文件系统驱动程序定义的inode 操作 生成，如他们没有什么是 inode 的概念，他们必须模仿所有 inode 的内部字段以符合 VFS，所以这个数字在之后可能会有所不同重新启动，甚至可能在关闭并再次打开文件之后(理论上)。

E.g. can it be automatically generated when a file is opened as opposed to being stored on the file system.

是的!非 Ext 文件系统的驱动程序(FAT32、NTFS)在访问其中一个文件时生成一个 inode 结构。

Can an application rely on it?

不是很安全，应用程序依赖于文件路径，这些文件路径更易于阅读。必须通过其 inode 查找文件将意味着遍历分区中的所有 inode(很多很多)。通过解析文件的路径，优化了搜索，它只检查目录中的文件。

Does a file system implementation need to guarantee specific semantics?

我不太了解这个问题，但我想是的，文件系统是非常复杂的结构，它们需要很好地确定它需要什么数据类型以及它们的含义。

例如:Ext 定义了block、inode 和dentry 以及这些函数的列表数据结构。

希望这对您有所帮助!