使用lseek SEEK_DATA/SEEK_HOLE枚举稀疏文件段结果异常排查

• 核心本质：lseek(2)的SEEK_DATA、SEEK_HOLE标记的段边界，完全以文件系统的物理块分配状态为判断依据，和逻辑上写入数据的字节偏移没有直接关系，和区域内容是不是全0也没有直接绑定关系。
• 测试所用ext4文件系统默认使用4KB（4096字节）作为磁盘空间分配的最小单位，单个物理块不能拆分分配：不存在一个块里一部分分配空间、一部分不分配的情况。
• 创建测试文件时在偏移10000字节位置写入5字节，这个写入位置落在起始偏移为8192字节的物理块（块范围是8192_{12287）范围内，ext4会直接为这整个块分配物理磁盘空间，块内未被写入的8192}9999字节区域会被默认填充为0，但因为块已经完成分配，这部分区域会被判定为数据段，而非空洞。
• 0~8191范围刚好对应前两个完整的4KB物理块，这两个块没有被分配任何物理存储空间，因此被判定为空洞段，和实际运行输出完全一致。
• 验证方式：可以用du 测试文件名命令查看文件实际磁盘占用，会发现10005字节的文件实际占用是4KB（一个物理块的大小），刚好对应8192起始的已分配块，可直接印证这个分配逻辑。
• 概念澄清：不要把「读取时返回全0」和「是稀疏空洞」划等号：稀疏空洞一定返回全0，但已分配块内的零值内容读取时也会返回全0，后者会实际占用磁盘空间，不属于SEEK_HOLE的识别范围。这个行为是SEEK_DATA/SEEK_HOLE接口的标准设计，不是ext4、内核或者glibc的bug，所有主流Linux本地文件系统都遵循这个判断逻辑。

根据对「空洞」的定义不同，有两种处理方向：

• 如果要识别的是文件系统层面真正不占磁盘空间的稀疏空洞：现有代码的输出是完全正确的，不需要修改。最初的逻辑预期错在混淆了逻辑写入位置和物理块分配规则——8192~9999这段虽然没有主动写入，但它已经占用了物理磁盘块，不属于稀疏空洞。如果想要测试出和最初预期一致的块边界，只需要在创建测试文件时，把写入位置调整为文件系统块大小的整数倍即可，比如将写入偏移设为12288（3*4096），此时写入位置刚好落在物理块起始边界，前面的所有块都不会被分配，就能得到[0,12287]为空洞、[12288,12292]为数据段的输出。
• 如果要识别的是逻辑上所有内容为全0的连续段（不区分是否分配物理块）：仅靠lseek的两个参数无法实现，需要补充两层逻辑：
  1. 首先用SEEK_DATA/SEEK_HOLE先拆分出未分配的物理空洞段（这些段一定是全0的）和已分配的数据段
  2. 对每个已分配的数据段，按固定粒度（比如块大小）读取内容做逐段校验，把段内部连续的全零区域拆分出来，标记为逻辑零值段即可。

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