1

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

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

4

2 回答 2

0

有趣的想法。

我对 ext3 不是很熟悉,但我可以给你一些一般性的指示。

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

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

要使这样的事情发生,创建一个新文件(即分配一个 inode)必须与当前的 ext3 文件系统完全不同。您必须分配一个空块并自己初始化它,而不是使用位图来查找未使用的、预分配和预初始化的 inode。因此,您可能想看看文件系统在写入文件时如何分配块,然后模仿它来分配 inode。

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

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

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

于 2010-12-06T02:19:08.313 回答
0

感谢进入文件系统设计!

首先,在深入研究黑客之前,请提供一些工程建议:制作 ext3 树的副本并将文件系统重命名为其他名称。我发现在将实验性更改引入文件系统时,您真的不希望它用于您的主系统。即使您引入了随机丢失文件的错误(最终会发生),您的系统仍应启动。您还需要分支 ext3 用户空间工具以使用您的新系统。

其次,去获取《 Understanding the Linux Kernel, 3 ed》的副本。播威和切萨蒂。它提供了一个有组织的内核子系统视图,我发现它的解释是值得的。它是为较旧的内核编写的(对于某些x < 15,为2.6.x;我完全忘记了),但它在许多地方仍然是准确的。通读它对文件系统的描述。我相信它涵盖了ext3。

第三,关于您的实际项目,您并不是提议对 ext3 进行简单的修改。该文件系统有一种非常直接的方式将 inode 编号映射到磁盘块。您需要找到一种新的方法来进行此映射。我预计不会对 ext3 的其余部分进行任何更改。解决这一挑战可能是您架构的关键设计点之一。请注意,保留大量 inode -> 磁盘块映射并不能解决您的问题:它可能并不比现有的 ext3 好。

于 2010-12-11T06:51:16.623 回答