3

我有一个令我困惑的问题，我的任务是解决碎片化问题。

stat() for a file:
st_size = 10520
st_blksize = 4096
st_blocks = 24

我在某些地方读到 st_blksize 是文件系统的一般块大小，在这种情况下是文件系统，4096但该文件适合3 blocks，10520 / 512这20.5意味着有3.5 blocks未使用的空间，即使它已分配。这是否意味着1792此文件中有未使用的字节（碎片）？

正如我所提到的，我对此进行了相当多的阅读并阅读了很多相互矛盾的文字，希望有人能一劳永逸地解决这个问题！

4

2 回答 2

1

我不认为你的项目在stat(2)API 层真的可以解决。考虑一个 4096 字节长的文件的情况。假设它是通过一遍又一遍地迭代附加 512 字节块而创建的。假设每次写入文件系统都已满，除了一个 512 字节的块。假设每次写入可用的 512 字节块位于磁盘上随机可用的位置。

该文件是 100% 碎片化的——没有两个块彼此靠近。

然而，仅基于stat(2)变量的度量很可能表明文件中的任何地方都没有浪费的块。

在试图找到您的实际问题的答案时，我ext3_write_begin()在被叫走之前就已经走到了尽头——希望这是您搜索的有用起点。

更新

如果您对查找碎片感兴趣，我认为开始的地方是程序中的bmap命令debugfs(8)：

debugfs:  bmap sars_first_radio_show.zip 0
94441752
debugfs:  bmap sars_first_radio_show.zip 1
94441781
debugfs:  bmap sars_first_radio_show.zip 2
94441782
debugfs:  bmap sars_first_radio_show.zip 3
94441783
debugfs:  bmap sars_first_radio_show.zip 4
94441784
debugfs:  bmap sars_first_radio_show.zip 5
94459905
debugfs:  bmap sars_first_radio_show.zip 6
95126019
debugfs:  bmap sars_first_radio_show.zip 7
95126020
debugfs:  bmap sars_first_radio_show.zip 8
95126021
debugfs:  bmap sars_first_radio_show.zip 9
95126022
debugfs:

这显示了文件的前十个块sars_first_radio_show.zip；您可以看到这些块并非都是连续的：944417{52,81,82,83,84}、94459905、951260{19,20,21,22}。

您可以编写一个答案，debugfs(8)也可以libext2fs自己使用库例程。stat(2)与您正在经历的练习相比，这将是复杂性的重要一步——但答案将意味着什么，而不仅仅是一个模糊的猜测。

于 2011-12-11T03:12:27.420 回答
0

IIRC st_blocks 必须报告 st_size / 512 以便各种 Linux 程序正常工作。它不一定与文件系统上分配了多少块有关。此外，st_blksize 仅告诉更高级别的应用程序读取和写入的大小以发送到系统调用以获得最佳性能。再一次，这并不一定意味着文件系统实际上是以这些块大小存储的东西。

关于文件碎片的问题的真正答案将高度依赖于您正在使用的 FS。我建议从较低的水平开始阅读

于 2016-03-14T17:03:56.767 回答