首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >更改inode行为

更改inode行为
EN

Stack Overflow用户
提问于 2010-12-06 05:58:00
回答 2查看 548关注 0票数 1

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

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

EN

回答 2

Stack Overflow用户

发布于 2010-12-06 10:19:08

有趣的想法。

我对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 Paper中编写完成。这些想法从未出现在FFS中,也没有出现在我所知道的任何其他主流文件系统中,所以看看它们在ext3中是如何工作的可能会很有趣。

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

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

票数 0
EN

Stack Overflow用户

发布于 2010-12-11 14:51:17

对进入文件系统设计的赞誉!

首先,在您深入了解黑客之前,有一点工程建议:复制ext3树并将文件系统重命名为其他名称。我发现,在将实验性更改引入文件系统时,您确实不希望将其用于您的主系统。即使你引入了一个随机丢失文件的bug (这最终会发生),你的系统应该仍然会启动。您还需要将ext3用户空间工具分支到您的新系统中。

其次,去买一份博维和塞萨蒂的Understanding the Linux Kernel, 3 ed.。它展示了内核子系统的一个有组织的视图,我发现它的解释是值得的。它是为更老的内核编写的(2.6.x对于某些x< 15;我完全忘记了),但它在许多地方仍然是准确的。通读它对文件系统的描述。我相信它涵盖了ext3。

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

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/4361483

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档