Longhorn项目中多副本备份镜像创建失败问题分析

问题背景

在Longhorn存储系统的使用过程中，用户报告了一个关于备份镜像创建的重要问题。当尝试从Longhorn卷导出备份镜像并设置最小副本数为3时，系统仅能成功创建一个副本，其余两个副本会陷入"启动-进行中-失败"的循环状态。这个问题在SLES操作系统上尤为明显，而在Ubuntu系统上则表现正常。

技术分析

问题现象

具体表现为：

1. 成功创建的副本能够正常进入"就绪"状态
2. 其他副本持续在以下状态间循环：
   • 启动(starting)
   • 进行中(in-progress)
   • 失败(failed)

错误日志显示，系统检测到了实际大小不匹配的问题：

found mismatching realSize 235278336 reported by backing image manager
backing-image-manager-b2c6-cc37 in disk cc376e72-1b18-49a3-a543-a6457a3ec75f,
the realSize recorded in status is 235282432

根本原因

经过深入分析，发现问题根源在于不同操作系统对文件实际大小的计算方式存在差异。具体表现为：

1. 在SLES-15sp6系统上：

   • 使用stat.Blocks * 512计算得到的文件大小为209715200字节
   • du -h命令显示为200MB

2. 在Ubuntu 22.04系统上：

   • 同样的计算方式得到209719296字节
   • du -h命令显示为201MB

值得注意的是，尽管文件大小计算存在差异，但文件的SHA512校验值在两个系统上完全一致，证明文件内容本身没有损坏或变化。

解决方案

开发团队针对此问题提出了以下改进措施：

1. 取消对文件实际大小的严格校验，因为：

   • 不同操作系统对文件块大小的处理方式不同
   • 文件内容的校验和已经能够保证数据一致性

2. 仅依赖校验和来验证备份镜像的完整性，因为：

   • 校验和是跨平台一致的文件完整性验证方式
   • 能够避免因操作系统差异导致的误判

验证结果

该修复已在Longhorn的主干分支和1.8.x分支中得到验证，确认解决了多副本备份镜像创建失败的问题。测试结果表明：

1. 在SLES系统上能够成功创建3个副本的备份镜像
2. 所有副本都能正常进入就绪状态
3. 不再出现副本状态循环的问题

技术启示

这个问题揭示了分布式存储系统开发中需要考虑的一个重要方面——跨平台兼容性。特别是在处理底层文件系统特性时，不同操作系统可能有不同的实现方式。开发团队总结出以下经验：

1. 文件大小计算可能因操作系统而异，不应作为数据一致性的唯一判断标准
2. 校验和是更可靠的跨平台数据完整性验证方式
3. 在分布式系统中，节点间的环境差异需要特别关注

这个问题及其解决方案为Longhorn项目在跨平台兼容性方面提供了宝贵的经验，将有助于未来类似问题的预防和解决。