Filesystems 改变inode行为

我正在尝试修改ext3文件系统。基本上，我希望确保文件的inode保存在与其存储元数据的文件相同（或相邻）的块中。希望这有助于提高磁盘访问性能

我抓取了内核源代码，编译了它，阅读了大量关于inode的内容，并查看了fs子目录中的inode.c文件。但是，我不确定如何确保创建的任何新文件以及该文件的inode都可以保存在相同或相邻的块中。如有任何进一步阅读的帮助或提示，将不胜感激。谢谢

有趣的想法

我对ext3不是很熟悉，但我可以给你一些一般性的建议

目前ext3将索引节点存储在预定的位置。每个块组都有自己的索引节点表，即索引节点数组。因此，当您有一个inode编号（即，作为在目录中查找文件名的结果）时，您可以在磁盘上找到相应的inode，方法是首先使用inode编号选择正确的块组，然后索引到该块组的inode表中

如果要将inode放在相应的文件数据旁边，则需要一个新的方案来查找磁盘上的inode。如果您愿意为每个inode指定一个块，那么一种可能的方案是在每次需要inode时分配一个新块，然后使用块号作为inode号。这样做的好处是，对于小文件，可以将数据存储在同一块中

要实现这种情况，创建一个新文件（即分配一个inode）的工作方式必须与当前ext3文件系统中的工作方式非常不同。与使用位图查找未使用、预分配和预初始化的inode不同，您需要分配一个空块并自己初始化它。因此，您可能希望了解文件系统在写入文件时如何分配块，然后模拟分配inode

另一种方案是将inode存储在目录中。因此，保存I/O并不是因为inode位于其数据旁边，而是因为在查找文件名时也读取了inode。早在90年代，这是在BSD的FFS文件系统中做的一个实验，并以一种优秀的方式编写。这些想法从未进入FFS，或者我所知道的任何其他主流文件系统，所以看看它们在ext3中是如何工作的可能会很有趣

无论您是采用这些方案中的一种，还是提出自己的方案，都必须修改mke2fs，以使新的文件系统变体能够理解的方式初始化磁盘上的文件系统

---

祝你好运！这听起来像是一个有趣的项目。

很荣幸能进入文件系统设计领域

首先，在深入黑客攻击之前，有一点工程建议：复制ext3树并将文件系统重命名为其他文件系统。我发现，在将实验性更改引入文件系统时，您确实不希望将其用于主系统。即使您引入了一个随机丢失文件的bug（它最终会发生），您的系统仍然应该启动。您还需要将ext3用户空间工具分支以与新系统配合使用

第二，去拿一份Bovet和Cesati的。它提供了一个有组织的内核子系统视图，我发现它的解释是值得的。它是为一个较旧的内核编写的（对于一些x<15的内核，它是2.6.x；我完全忘记了），但在很多地方它仍然是准确的。通读它对文件系统的描述。我相信它涵盖了ext3

第三，关于您的实际项目，您没有建议对ext3进行简单的修改。该文件系统有一种非常简单的方法将索引节点号映射到磁盘块。您需要找到一种新的方法来进行此映射。我预计ext3的其余部分不会有任何变化。解决这一挑战可能是您的体系结构的关键设计点之一。请注意，保留一个大的inode->磁盘块映射数组并不能解决您的问题：它可能并不比现有的ext3好