inode 和 crtime 可以用作唯一的文件标识符吗？答案

【问题标题】：Can inode and crtime be used as a unique file identifier?inode 和 crtime 可以用作唯一的文件标识符吗？
【发布时间】：2013-04-10 19:08:08
【问题描述】：

我在 Linux 上有一个文件索引数据库。目前我使用文件路径作为标识符。但是如果一个文件被移动/重命名，它的路径就会改变，我无法将我的数据库记录与新文件匹配，并且必须删除/重新创建记录。更糟糕的是，如果一个目录被移动/重命名，那么我必须删除/重新创建所有文件和嵌套目录的记录。

我想使用 inode 编号作为唯一的文件标识符，但如果删除文件并创建另一个文件，则可以重复使用 inode 编号。

所以，我想知道我是否可以使用一对{inode,crtime} 作为唯一的文件标识符。我希望在 ext4 上使用 i_crtime，在 NTFS 上使用 creation_time。在我有限的测试（使用 ext4）中，inode 和 crtime 在同一文件系统中重命名或移动文件或目录时确实保持不变。

所以，问题是是否存在文件的 inode 或 crtime 可能发生变化的情况。例如，fsck 或碎片整理或分区调整大小是否可以更改 inode 或 crtime 或文件？

有趣的是 http://msdn.microsoft.com/en-us/library/aa363788%28VS.85%29.aspx 说：

"在 NTFS 文件系统中，一个文件在被删除之前保持相同的文件 ID。"
还有：
“在某些情况下，文件的文件 ID 会随着时间而改变。”

那么，他们提到的那些案例是什么？

请注意，我研究过类似的问题：

但他们没有回答我的问题。

【问题讨论】：

{device_nr, inode_nr} 是系统上文件（“inode”）的唯一 ID。这些保证是稳定的（也许，但 NFS 除外）移动文件不会更改 inode，它只是将指向 inode 的链接移动到另一个目录。跨文件系统移动是不同的。顺便说一句：微软文档提到 NTFS 作为规则的一个可能的例外（就像我的 NFS 例外，可能还有 NAS/SAN 存储？）
顺便说一句：什么是 crtime？ UFS 只有 {ctime,atime,mtime}
crtime 是文件创建时间。它是在 ext4 中添加的。其他帖子中对此进行了详细讨论。
对于 Linux，因为 inode 可以在 NFS 中重复使用，并且因为您可能在 NFS 上索引文件，所以您不能只使用 INODE（我们同意这一点）。因此，对于 Linux，我将使用 inode 和 inode 生成作为唯一键。让我们知道您采用了什么解决方案（这个问题没有答案）。

标签： linux inode

【解决方案1】：

{device_nr,inode_nr} 是系统内一个 inode 的唯一标识符
将文件移动到其他目录不会更改其 inode_nr
linux inotify 接口使您能够监控对 inode（文件或目录）的更改

补充说明：

移动文件跨文件系统的处理方式不同。（实际上是复制+删除）
联网文件系统（或挂载的 NTFS）不能始终保证 inodenumber 的稳定性
Microsoft 不是 Unix 供应商，它的文档不涵盖 Unix 或其文件系统，应该被忽略（NTFS 的内部结构除外）

额外文字：旧的 Unix 格言“一切都是文件”实际上应该是：“一切都是 inode”。 inode 携带关于文件（或目录，或特殊文件）的所有元信息除了名称。文件名实际上只是碰巧链接到特定 inode 的目录条目。移动文件意味着：创建一个指向同一个 inode 的新链接，结束删除链接到它的旧目录条目。可以通过stat() 和fstat() 和lstat() 系统调用获取inode 元数据。

【讨论】：

wildplasser 写道：“{device_nr, inode_nr} 是系统上文件（“inode”）的唯一 ID。这些都保证是稳定的“...... .......... 由谁“保证”？你有一些文档的参考吗？因为快速搜索“保证是稳定的”inode 会带来“inode numbers are -not-保证是稳定的”.......另外，inode 不是足够了，因为它们可以重复使用。所以，我决定也使用 crtime。我需要了解它的稳定性。
如果 inode 编号被重用，它首先必须是未使用的。（如果链接计数变为零，则 inode 未使用/不存在，然后它可以被重用，包括它的编号）参见 stat(2) 核心信息：参见 Bach 或源+ 文件系统文档 + 驱动程序。
wildplasser 写道：“如果 inode 编号被重用，它首先必须是未使用的。” jhnlmn：当然，我写了“但是如果删除文件并创建另一个文件，则可以重用 inode 编号。”在我的问题中
inode 号是文件系统上现有文件的标识符。将其存储在数据库中然后删除文件就像在 DBMS 中获取外键一样，没有 CASCADE 选项。您的系统仍会通过现在引用不同实体的数字来引用不再存在的文件。解决方法很简单：不要删除文件，如果删除文件：删除所有对它的引用。
wildplasser 写道: 微软不是一个 Unix 供应商，它的文档不包括 Unix 或其文件系统，应该被忽略 jhnlmn: 这是不正确的。可以将磁盘插入 Linux，然后插入 Windows，然后再插入 Linux。或者 Windows 和 Linux 可能在双引导系统上依次引导。因此，了解 MS 如何处理文件 ID 同样重要。现在我对 Windows 下 NTFS 中文件 ID 的稳定性比在 Linux 下更有信心，Linux 下的文档较少。

【解决方案2】：

Unix 中 i 节点的分配和管理取决于文件系统。因此，对于每个文件系统，答案可能会有所不同。

对于 Ext3 文件系统（最流行的），索引节点被重用，因此不能用作唯一的文件标识符，重用也不会按照任何可预测的模式发生。

在 Ext3 中，i 节点在位向量中进行跟踪，每个位代表一个 i 节点编号。当一个 i 节点被释放时，它的位被设置为零。当需要一个新的 i 节点时，会在位向量中搜索第一个零位，并重新使用 i 节点编号（可能先前已分配给另一个文件）。

这可能会导致一个幼稚的结论，即编号最小的可用 i 节点将被重用。然而，Ext3 文件系统复杂且高度优化，因此不应假设何时以及如何重用 i 节点编号，即使它们显然会这样做。

来自 ialloc.c 的源代码，其中分配了 i 节点：

有两种分配 inode 的策略。如果新的 inode 是目录，然后向前搜索一个块组可用空间和较低的目录与 inode 比率；如果失败，那么他组的空闲空间高于平均水平，该组的空闲空间最少目录已经被选中。对于其他 inode，向前搜索父目录的块组来寻找空闲的inode。

为 Ext3 管理这个的源代码称为 ialloc，最终版本在这里：https://github.com/torvalds/linux/blob/master/fs/ext3/ialloc.c

【讨论】：

当然，inode是可以复用的，我一开始就提到了。我的问题是一对 {inode,crtime} 是否可以用作唯一标识符，特别是这些值是否可以更改现有文件。
答案取决于您是否愿意承担文件系统算法会发生变化的风险。目前，i-node 编号在删除文件之前不会更改。此外，当使用 truncate(2) 截断文件时，内核不会更改 i 节点编号。然而，许多程序在修改文件时会重新创建文件，从而更改 i 节点编号。如果您已经编写了所有相关的软件，并且明确知道 i-node 本身不会被删除，那么您可以冒险，至少在 ext3 文件系统上是这样。考虑到因素的数量，我会谨慎。
您知道具有动态 inode 的文件系统如何与重用 inode 相关吗？即使在动态分配新的 inode 时，ZFS 和 BTRFS 是否也重用 inode。所有这些技术都是基于位向量的吗？如果有一百万个文件，那么这个 inode 位向量会有一百万位吗？

【解决方案3】：

我想 dB 应用程序需要考虑文件需要从备份恢复的情况，这将保留文件 crtime，但不保留 inode 编号。

【讨论】：