以下是我的统计输出：
[alankoh@SJOAM swap]$ stat myswapfile
File: `myswapfile'
Size: 2147483648 Blocks: 4194312 IO Block: 4096 regular file
Device: fd03h/64771d Inode: 1179650 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2015-08-06 16:22:28.672852866 +0800
Modify: 2015-07-02 07:39:04.781064916 +0800
Change: 2015-07-02 07:39:04.809064917 +0800
分配的块（4194312）是否包括索引节点本身的大小，还是指“实际数据”部分？
那么我们如何找到上述inode的大小呢？
物理块的大小为 512 x 4194312 分配的块 = 2147487744 字节
文件大小为 2147483648 字节
2147487744 - 2147483648 = 4096 字节
4096 字节 = IO 块
上述相关计算与IO Block有何关系？ IO 块是每次文件需要空间时的每个分配单元吗？ 4096 = 8 块 x 512 字节？
答案1
“块”值是多少（st_blocksa 的字段struct stat）的测量结果并不标准化。
传统上，它计算用于文件系统内容的块的数量；该值乘以块大小等于文件大小，四舍五入到最接近的块大小倍数。有一个例外：如果文件是稀疏文件，那么它使用更少的块。这留下了一些未解释的事情：
- 文件元数据消耗的空间：时间戳、权限等。在传统的 Unix 布局中，这些元数据存储在 inode 中，但现代文件系统可以拥有大量元数据（用于访问控制列表、扩展安全属性等），而这并不需要很大的元数据。始终适合固定大小的索引节点。
- 间接块消耗的空间：对于大文件，包含文件内容的块列表本身可能会占用许多块。
- 目录条目（或条目，如果文件有多个硬链接）消耗的空间。该空间占目录本身的大小。
我不知道有哪个文件系统将索引节点大小报告为值的一部分st_blocks。大多数 Unix 文件系统都有一个将 inode 与其余内容分开的布局，并分别跟踪 inode 使用情况和块使用情况。有些文件系统包含间接块st_blocks，有些则不包含。
还有其他因素可能会导致块大小和内容大小之间的差异。例如，在压缩文件系统上，这种关系取决于文件可以压缩的程度。一些文件系统可以在几个小文件或较大文件的尾部之间共享一个块，例如，一个 1024 字节的块可以包含一个 200 字节的文件和一个 1124 字节文件的最后 100 字节，并且该块将被计入st_blocks两个文件的值。
“IO Block”值（st_blksize的字段struct stat）与“Blocks”值没有任何关系。该st_blksize值向应用程序暗示，如果在读取或写入文件时使用此大小的缓冲区，它们将获得更好的性能。在具有复杂性能特征的现代系统上，它可能有也可能没有任何相关性。
在许多系统上，该值的单位st_blocks是f_bsize来自struct statvfs。该单位可能因文件系统而异（即使是相同类型的文件系统，例如 ext4 也可以使用 1024、2048 或 4096）。我认为 Linux 上总是如此，但 POSIX 不能保证这一点。在 Linux 上，您可以f_bsize使用 来显示该值stat -f。
该du实用程序在计算文件的磁盘使用情况时将进行正确的计算：所做du的是将该st_blocks值乘以适当的块大小（因此在大多数系统上它不包括索引节点）。
没有通用的方法来查找索引节点的大小。某些文件系统类型使用固定大小的索引节点，您可以在文件系统的定义中查找它们。某些文件系统类型对给定文件系统使用固定大小，您可以使用实用程序进行查询（例如，tune2fs对于 ext[234]）。
答案2
使用tune2fs 确定文件系统的inode 大小。
$ df -k /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 9156984 7509468 1159324 87% /
$ tune2fs -l /dev/sda1|grep "^Inode size:"
Inode size: 256
$