Question

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

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

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

正如我所提到的，我读了很多内容并阅读了很多矛盾的文本，希望有人能够一劳永逸地解决这个问题！

Answer 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)练习相比，这将是一个复杂的重要步骤 - 但答案将意味着什么，而不仅仅是一个模糊的猜测。

Answer 2

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

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

STAT块大小/块使用

2 个答案: