已缓存文件执行/usr/bin/time -v为何file inputs数值不为零？

你遇到的核心误区是对ru_inblock（对应/usr/bin/time -v的file inputs）的统计逻辑理解偏差——它并非仅统计磁盘物理IO，而是内核中所有通过块设备层完成的输入操作都会被计入，哪怕数据最终来自页缓存而非磁盘。结合你的场景，具体原因可以从以下几点分析：

1. 页缓存的预读机制未全量加载文件 #

cat foo >> /dev/null触发的页缓存预读是按内核默认的预读窗口（通常是几MB到几十MB）逐步加载的，并非一次性将2.5GB文件全部载入内存。后续你的mmap程序访问未被预读的页时，内核会触发页缓存填充操作，这一过程会走块设备层的处理路径，即便数据来自内存缓存，也会被统计到ru_inblock中。

2. 内存管理的隐性操作 #

即便系统内存充足（32GB远大于2.5GB文件），内核的内存回收策略仍可能将少量页缓存临时置换到swap分区（比如为了维持内存碎片整理或其他内核操作）。当你的mmap程序访问这些被置换的页时，需要从swap分区读取数据，这会被算作块输入操作，导致ru_inblock增长。

3. mmap访问触发的块层元数据操作 #

通过mmap映射文件后，首次访问某页时（即便属于软页错误ru_minflt），内核需要完成页缓存到进程地址空间的映射，期间可能涉及块设备层的元数据交互：

• 校验页缓存的有效性、更新页状态标记
• 读取文件系统的索引节点（inode）扩展属性或其他元数据（即便这些元数据已在缓存中）
  这些操作都会被计入ru_inblock统计。

验证方法 #

• 用iostat -x 1或vmstat 1观察磁盘物理IO指标（r/s、%util），如果这些数值没有明显波动，说明确实没有磁盘IO，ru_inblock统计的是缓存相关的块层操作。
• 尝试用大尺寸块读取文件以全量载入缓存：dd if=foo of=/dev/null bs=1G，再运行你的程序，观察ru_inblock是否显著减少。

内容的提问来源于stack exchange，提问作者Jacko