使用dd分块读取大二进制文件传下游进程时返回块大小小于设定值的问题排查

你观察到的131072字节（即128KiB）分块结果，是两个系统机制叠加产生的必然现象：

• 131072这个数值本身就是当前主流Linux系统的两个默认配置值：管道的内核默认缓冲区大小为128KiB，glibc标准IO库的默认块缓冲大小也是128KiB。
• GNU dd处理非可寻址输入（管道、套接字等无法通过偏移量定位的输入流）时存在默认行为：它不会为了凑够bs参数指定的块大小反复读取数据，只要单次系统调用拿到任意长度的字节，就会将这批字节作为一个完整块立刻输出给下游，同时完成一次count计数。

两者的作用链路是：上游的第一个dd从磁盘读入1MiB数据向管道写入，因为管道缓冲区只有128KiB，写满后会进入阻塞状态；下游循环中的dd启动后，第一次读取系统调用就会把管道缓冲区中全部128KiB数据读走，直接当成完整块传给processor，根本不会等待剩下的768KiB数据从管道传输过来，最终就出现了块大小远小于设定值的问题。

根据目标（直接提取固定大小分块，不落地写临时文件，将每个分块作为输入传给后续处理进程），可以根据使用习惯选择以下两种可靠方案：

• 修正原有dd循环方案
  只需要给循环内负责从管道读数据的dd加上iflag=fullblock参数，强制dd不管输入类型，都反复调用read直到凑够bs * count的字节数才返回，彻底解决半块读取的问题。同时利用dd的退出码做循环退出判断，避免文件读取完成后空转。修正后的参考命令：

  dd if=some_big_file bs=1M | \
  while dd bs=1M count=1 iflag=fullblock 2>/dev/null | processor; do
      :
  done
  

  当文件全部读取完成，最后一段不足1M的数据读完后，dd会因为无法凑够完整块返回非0退出码，循环自动终止。
• 更高效的原生分块方案
  直接使用GNU split内置的--filter参数实现需求，完全不需要手写循环逻辑。该参数的作用是：split按照指定大小切分文件时，每切完一个完整块，就启动你指定的处理命令，将当前块的全部内容作为命令的标准输入，全程不会在磁盘上生成独立的分段临时文件。参考命令：

  split -b 1M --filter='processor' some_big_file
  

  该方案对比手写dd循环的优势：
  • 无重复fork子进程的额外开销，文件读取和分块逻辑都在split进程内完成，性能和直接将分块写入文件的场景基本无差异。
  • 天然规避半块读取问题，split的分块逻辑本身就是凑够指定字节数再传递，不存在和dd一样的单次read截断块的问题。
  • 自动处理文件末尾的不完整块，不需要额外编写退出判断逻辑，命令复杂度远低于自写循环实现。

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