ZFS 16k记录大小替代128k的弊端及QEMU磁盘镜像相关技术咨询
首先得说，你用sysbench和tpcc测出来的40%TPS提升、25%延迟降低确实很亮眼，这也印证了ZFS记录大小和数据库页大小匹配的重要性。接下来咱们聊聊你关心的两个问题：
一、使用16k记录大小替代128k的潜在弊端
结合你的实际使用场景（PHP容器、Java日志、MySQL、备份、大gzip文件），换成全局16k记录大小主要会遇到这些问题：
空间利用率下降：ZFS的记录大小是最小的分配与写入单元，16k比默认的128k小很多，意味着相同数据会被拆分成更多的块，元数据（比如块指针、校验和）的占比会显著提升。尤其是你的大文件场景——比如备份压缩包、Java应用的大日志文件，小记录大小会让ZFS无法高效合并连续写入，浪费更多存储空间。另外，如果开启了ZFS压缩，16k的小记录块压缩效率通常不如128k的大块（压缩算法处理更大的连续数据时，压缩比更高），进一步降低空间利用率。
大文件读写性能损耗：对于顺序读写占主导的场景（比如本地备份/恢复、大gzip文件处理），16k记录大小会导致IO请求数激增。举个例子，写入1GB的文件，用128k记录只需要约8000次IO，而16k则需要约64000次——哪怕单次IO延迟差不多，总吞吐量会明显下降，CPU处理IO请求的开销也会增加。这对你的备份操作、大日志文件的追加写入都会有可见的影响。
CPU使用率上升：更多的记录块意味着ZFS需要处理更多的校验和计算、元数据更新、压缩/解压缩操作（如果开启了压缩）。虽然MySQL场景下的CPU开销可能被性能提升抵消，但在其他场景（比如批量备份、大文件处理），CPU占用率会比用128k记录时更高，极端情况下可能成为系统瓶颈。
二、QEMU磁盘镜像的“页大小”相关问题
你当前使用的是raw格式的QEMU镜像，这种格式本身没有类似innodb_page_size的固定页/簇大小——它本质上就是一块“裸磁盘”，读写粒度由两个层面共同决定：
- 宿主机ZFS的记录大小：ZFS会以自己的记录大小为单位来处理raw镜像的读写，这也是你之前测试MySQL性能时，16k记录大小匹配InnoDB页大小能提升性能的核心原因。
- 虚拟机内部的文件系统块大小：比如你容器里用的ext4，默认块大小可能是4k或16k，当虚拟机内部写入数据时，最终会映射到ZFS的记录块上。如果两者大小匹配（比如虚拟机内用16k块，ZFS也是16k记录），就能避免“写放大”——不会出现一个虚拟机内的块需要跨多个ZFS记录块的情况。
如果是qcow2格式的QEMU镜像，它有自己的cluster大小（默认64k），这个cluster大小就类似InnoDB的页大小，是qcow2内部的最小分配单元。但你目前用的是raw，所以不需要考虑这个。
备注：内容来源于stack exchange，提问作者Kamil
