linux - stat命令如何计算文件的 block ？

Question

我想知道 stat 命令如何计算文件的 block 数。我读了这个article上面写着:

The value st_blocks gives the size of the file in 512-byte blocks. (This may be smaller than st_size/512 e.g. when the file has holes.) The value st_blksize gives the "preferred" blocksize for efficient file system I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.)

但我无法通过自己的测试来验证这一点。

我的文件系统是ext3。

命令 dumpe2fs -h/dev/sda3 显示:

...
First block: 0
Block size: 4096
Fragment size: 4096
...

然后我跑

kent@KentT60:~/Desktop$ stat Email
File: `Email'
Size: 965 Blocks: 8 IO Block: 4096 regular file
Device: 80ah/2058d Inode: 746095 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ kent) Gid: ( 1000/ kent)
Access: 2009-08-11 21:36:36.000000000 +0200
Modify: 2009-08-11 21:36:35.000000000 +0200
Change: 2009-08-11 21:36:35.000000000 +0200

如果这里的“Blocks”的意思是:“有多少个512字节的 block ”，这个数字应该是2，而不是8。我以为文件系统(IO block )的 block 大小是4k。

如果文件系统获取文件 Email，它将从磁盘中获取至少 4k(8 x 512 字节 block )，这意味着 965/512 + 6 = 8。我不是确定这个猜测是否正确。

另一个测试:

kent@KentT60:~/Desktop$ stat wxPython-demo-2.8.10.1.tar.bz2
File: `wxPython-demo-2.8.10.1.tar.bz2'
Size: 3605257 Blocks: 7056 IO Block: 4096 regular file
Device: 80ah/2058d Inode: 746210 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ kent) Gid: ( 1000/ kent)
Access: 2009-08-12 21:45:45.000000000 +0200
Modify: 2009-08-12 21:43:46.000000000 +0200
Change: 2009-08-12 21:43:46.000000000 +0200


3605257/512=7041.xx = 7042

根据我上面的猜测，这将是 7042 + 6 = 7048。但是 stat 结果显示 7056。

另一个示例来自互联网 https://www.computerhope.com/unix/stat.htm。我将示例粘贴在页面底部:

File: `index.htm'
Size: 17137 Blocks: 40 IO Block: 8192 regular file
Device: 8h/8d Inode: 23161443 Links: 1
Access: (0644/-rw-r--r--) Uid: (17433/comphope) Gid: ( 32/ www)
Access: 2007-04-03 09:20:18.000000000 -0600
Modify: 2007-04-01 23:13:05.000000000 -0600
Change: 2007-04-02 16:36:21.000000000 -0600

在此示例中，文件系统 block 大小为 8k。我想“ block ”值应该是 16xN，但它是 40。我迷路了......

谁能解释一下 stat 是如何计算“Blocks”值的？

谢谢!

Answer 1

stat命令行工具使用stat/fstat等函数，返回数据在stat结构。 stat 结构的 st_blocks 成员返回:

The total number of physical blocks of size 512 bytes actually allocated on disk. This field is not defined for block special or character special files.

因此，对于您的“电子邮件”示例，大小为 965， block 数为 8，表示在磁盘上物理分配了 8*512=4096 字节。它不是 2 的原因是磁盘上的文件系统不以 512 为单位分配空间，它显然以 4096 为单位分配它们。(分配单位可能因文件大小和文件系统复杂性而异。例如 ZFS 支持不同的分配单位。)

同样，对于wxPython的例子，它表示在磁盘上物理分配了7056*512字节，即3612672字节。你明白了。

IO block 大小是“关于 I/O 操作的‘最佳’单位大小的提示”——它通常是物理磁盘上的分配单位。不要混淆 IO block 和 stat 用来指示物理大小的 block ；物理大小的 block 始终为 512 字节。

根据评论更新:

正如我所说，st_blocks 是操作系统指示磁盘上文件使用了多少空间的方式。磁盘上的实际分配单位是文件系统的选择。例如，ZFS 可以有可变大小的分配 block ，甚至在同一个文件中，因为它分配 block 的方式:文件开始时 block 大小很小， block 大小不断增加直到它达到了一个特定的点。如果文件后来被截断，它可能会保留旧的 block 大小。所以根据文件的历史，它可以有多种可能的 block 大小。因此，给定一个文件大小，为什么它具有特定的物理大小并不总是很明显。

具体示例:在我的 Solaris 机器上，使用 ZFS 文件系统，我可以创建一个非常短的文件:

$ echo foo > test
$ stat test
  Size: 4               Blocks: 2          IO Block: 512    regular file
(irrelevant details omitted)

好的，小文件，2 个 block ，此文件的物理磁盘使用率为 1024。

$ dd if=/dev/zero of=test2 bs=8192 count=4
$ stat test2
  Size: 32768           Blocks: 65         IO Block: 32768  regular file

好的，现在我们看到物理磁盘使用量为 32.5K，IO block 大小为 32K。然后我将它复制到 test3 并在编辑器中截断这个 test3 文件:

$ cp test2 test3
$ joe -hex test3
$ stat test3
  Size: 4               Blocks: 65         IO Block: 32768  regular file

现在，这是一个包含 4 个字节的文件 - 就像 test - 但由于 ZFS 文件系统分配空间的方式，它在磁盘上实际使用了 32.5K。 block 大小会随着文件变大而增加，但不会随着文件变小而减小。 (是的，这可能会导致大量空间浪费，具体取决于您在 ZFS 上执行的文件类型和文件操作，这就是为什么它允许您在每个文件系统的基础上设置最大块大小，并动态更改它。)

希望您现在可以理解文件大小和物理磁盘使用率之间不一定存在简单的关系。即使在上面，也不清楚为什么需要 32.5K 字节来存储大小恰好为 32K 的文件——似乎 ZFS 通常需要额外的 512 字节来存储它自己的额外空间。也许它正在将该存储用于校验和、引用计数、事务状态 - 文件系统簿记。通过在指示的物理文件大小中包含这些额外内容，ZFS 似乎试图不在文件的物理成本方面误导用户。这并不意味着在不知道有关底层文件系统实现的详细信息的情况下对计算进行逆向工程是微不足道的。