我想知道是否将有关文件的信息存储在索引节点而不是直接在目录中值得额外的开销。我可能高估了开销或忽略了一些重要的事情，但这就是我问的原因。
我发现像“inodes”这样的东西对于硬链接是必要的，但是如果开销真的像我想象的那么大，我想知道是否任何原因证明它是合理的：
- 使用硬链接进行备份很聪明，但与正常操作的效率相比，备份的效率不够重要
- 硬链接的速度和大小都没有损失确实很重要，因为这种优势仅存在对于几个文件在访问时使用硬链接全部文件承受开销
- 为几个同名的二进制文件（例如
bunzip2和 ）节省一些空间bcat可以忽略不计
我并不是说索引节点/硬链接不好或无用，但它是否可以证明额外间接的成本是合理的（缓存肯定有很大帮助，但它不是灵丹妙药）？
答案1
硬链接不是重点。它们不是拥有 inode 的原因。它们是一个副产品：基本上，任何合理的类 UNIX 文件系统设计（甚至 NTFS 在这一点上也足够接近）都有免费的硬链接。
inode 是存储文件所有元数据的地方：修改时间、权限等等。它也是磁盘上文件数据的存储位置。这些数据必须存储在某个地方。
将索引节点数据存储在目录中会产生一定的开销。它使目录变大，从而获取目录列表的速度变慢。您可以为每次文件访问保存一次查找，但每次目录遍历（访问一个文件需要多次遍历，文件路径上的每个目录一次）的成本稍高一些。最重要的是，这使得将文件从一个目录移动到另一个目录变得更加困难：您需要移动所有元数据，而不是仅移动指向 inode 的指针。
Unix 系统始终允许您重命名或删除文件，即使进程已打开该文件。 （在某些 UNIX 变体上，几乎总是这样做。）这在实践中是一个非常重要的属性：它意味着应用程序无法“劫持”文件。重命名或删除文件不会影响应用程序，它可以继续读取和写入文件。如果文件被删除，数据将保留下来，直到没有进程再打开该文件。通过将进程与索引节点相关联可以促进这一点。该进程不能与文件名关联，因为文件名可能随时更改甚至消失。
也可以看看什么是超级块、索引节点、目录项和文件？
答案2
您可能错过了其他一些因素。目录中索引节点与文件名的分离启用了硬链接，但我怀疑硬链接构成了这种分离的唯一动机，甚至是最初的动机。
我有一份 1978 年 7 月至 8 月的《贝尔系统技术期刊》。这是他们的特刊之一，标题为《Unix分时系统》。这是 Thompson、Ritchie 和公司发布他们对 Unix 版本 6 和 7 的描述以及您可以用它做什么的地方。
我看到了索引节点和文件系统的描述，但没有设计的动机。 Ritchie 和 Thompson 注意到create（他们在 BSTJ 中的拼写）系统调用生成 inode 并设置值，而open系统调用则填充操作系统表，该表可以在进一步的文件访问时保存 inode 数据。
其中一个关键段落讨论了保存 inode 的磁盘块，他们将其称为 i-list：
i-list 的概念是 UNIX 的一个不寻常的特性。在实践中，这种组织文件系统的方法已被证明相当可靠且易于处理。 ...它还允许使用一种非常简单且快速的算法来检查文件系统的一致性，...该算法独立于目录层次结构，因为它只需要扫描线性组织的i-list。
—来源
最初的设计者发现，将索引节点与数据分开可以使事情变得更加可靠。
我相信我们可以凭借多年的经验来实现这一点。 MS-DOS 和其他目录层次结构与分配 (FAT) 混合在一起的文件系统非常脆弱。如果FAT中的某个扇区坏了，就很难恢复了。但是，如果 Unix 目录中的某个扇区坏了，那么磁盘上其他位置的 inode 仍然存在，并且有一个链接计数表明它属于某个目录，因此可以恢复。
看起来，在目录中查找索引节点号，然后在索引节点中查找权限或数据的明显开销，可以通过使操作系统对文件的处理更简单或通过更高的可靠性来补偿。
答案3
1个实用的inode示例：
您有一个名称很棘手的文件（例如 ~*），您需要将其删除。
ls
~*
rm -rf ~*损坏您的 $HOME，因此您必须以其他方式删除它。
读这里如何通过inode删除文件。
通过inode删除文件：
find . -type f -inum 1234 - exec rm -rf {} /;
好吧，我知道你可以转义特殊字符并简单地用 rm 删除它，或者使用 -- 技巧，但仍然如此。
答案4
硬链接不仅仅用于文件；还用于文件。.是文件系统中的实际链接，因此每个目录至少有两个文件系统链接——完整路径名和.链接。添加..链接，一个目录可以有多个硬链接。