Linux 重新启动后的索引节点号

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

inode

不是每个文件系统的通用概念

Ext

文件系统和Linux

VFS

将

inode

视为存储文件信息的数据结构。但是，例如，

FAT32

或

NTFS

不知道

inode

是什么，因为他们根本不使用这个概念

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

重新启动、重新装载或甚至在所有进程关闭inode然后再次打开后，inode编号是否保证（例如，通过标准）相同

取决于，如果文件系统是

Ext

类型，则

inode

编号存储在

struct inode

内的

i_ino

文件中，该文件写入磁盘，因此，在这种情况下，如果文件相同（而不是其他同名文件），则为是然后保证

inode

编号相同

否则，如果文件系统不是

Ext

，则

inode

编号是由文件系统驱动程序定义的

inode操作生成的，因为它们不知道
inode
是什么，它们必须模拟所有
inode
的内部字段以符合VFS，因此，重新启动后，该数字可能会有所不同，即使在再次关闭和打开文件后，理论上也可能会有所不同

例如，当打开文件而不是存储在文件系统中时，可以自动生成该文件

对!！非
Ext
文件系统的驱动程序（
FAT32
，
NTFS
）在访问其文件时生成
inode
结构

应用程序可以依赖它吗

不是很安全，应用程序依赖于文件路径，而文件路径更易于人类阅读。必须通过
inode
查找文件意味着在分区（多个）中循环所有
inode
。通过解析文件路径，搜索得到优化，它只检查目录中的文件

文件系统实现是否需要保证特定的语义

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

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

希望这有帮助
 你打算如何使用它？没有一个user-land-API接受inode编号（由于只有组合是唯一的，所以可能是设备编号）并返回文件名或文件描述符。这是为内核中的文件系统代码保留的。您可以确信，如果inode编号与重新启动前不同，则文件已更改。如果inode编号是相同的，你就不会那么自信；您所知道的是，相同的名称映射到相同的编号，但在此期间可能会有删除和重新创建操作——inode也可能有其他名称。我主要考虑的是对文件系统驱动程序的要求。FS驱动程序在读取目录树时是否有自由修改inode编号，还是会破坏应用程序。更好的是，有一个标准，它会打破预期的语义。您的评论似乎表明inode是一个方便文件系统的指针，不能完全依赖于它。。。如果文件没有更改，“ls-i”是否可以输出不同的inode？我不知道inode编号是否有必要的语义，但我知道1）并非所有文件系统都有inode的概念，因此从中获得的任何“inode编号”都是合成的，2）在大多数文件系统上，inode编号往往是静态的，有时在文件系统创建时分配和索引，有时基于存储它们的磁盘位置等。这样可能更简单……您知道一个文件系统的示例吗？在单个装载会话期间为同一文件生成不同的inode编号？我不能肯定，但我想你可以自己试试。在Linux上安装FAT32或NTFS驱动器，播放一些文件，每次更改后执行
ls-i
。可能它们不会改变，因为它们会被缓存，但它们绝对是不真实的。从我所看到的，在fat和ntfs中，inode不会改变，它们会被映射，指向fat的指针，或者ntfs的集群号。我希望有人能找到答案，我不需要花费数周的时间来处理每一个文件系统，然后发现BSD的语义与Linux不同，或者POSIX说了一些特定的要求，这些要求要么没有实现，要么很难观察到。没有人可能会改变。改变它是一个昂贵的操作，根本没有必要。操作系统可能会在第一次缓存并维护它。试着读一些关于VFS的东西。@Martin在Linux中刚刚做了，
touch x
，用
294959
id创建并插入，然后
rm x
，
touch y
和
y
的inode重用了id
294959
。它说了什么吗？