Incus项目中LINSTOR存储池大小报告问题的分析与解决

问题背景

在Incus项目中使用LINSTOR作为存储驱动时，发现存储池大小的报告存在不准确的问题。LINSTOR驱动当前使用的是query-size-info API端点来获取存储池大小信息，但这个API的行为与预期不符。它实际上返回的是所有节点中最小的可用空间值，而不是整个存储池的总可用空间。

问题分析

LINSTOR是一个分布式存储解决方案，它管理多个节点上的存储资源。在当前的实现中，当查询资源组(Resource Group)的大小时，系统会返回单个节点上的最小可用空间值。这对于平衡的存储池来说虽然技术上不算错误，但会给用户带来误导，因为：

1. 用户期望看到的是整个集群的总可用空间
2. 实际可用空间可能远大于报告值
3. 无法反映集群的真实存储容量

技术细节

通过分析LINSTOR的API行为，我们发现：

• query-size-info端点返回的是集群中单个节点上的最小可用空间
• 每个节点都有自己的存储池配置
• 资源组可以跨多个节点分配存储资源

示例数据显示，虽然每个节点都有约23TiB的可用空间，但系统只报告了单个节点的值，而实际上集群总可用空间应该是各节点之和。

解决方案

经过讨论，我们决定采用以下改进方案：

1. 遍历与资源组关联的所有存储池
2. 汇总各节点的free_capacity和total_capacity值
3. 计算集群范围内的总使用情况
4. 返回聚合后的存储信息

这种方案更符合用户预期，能够真实反映集群的存储容量。实现时需要注意：

• 通过资源组的AutoSelectFilter字段获取关联的存储池
• 使用ListOpts过滤存储池列表
• 正确处理可能的空值或异常情况

实现考量

在实现过程中，我们考虑了以下因素：

1. 资源组可能有的额外限制（虽然LINSTOR目前不支持）
2. 存储池的过度配置比例(Oversubscription Ratios)
3. 单卷不能跨节点的限制
4. Incus对驱动验证的依赖

最终确认当前方案不会影响Incus的正常运行，因为：

• Incus仅将这些信息用于用户报告
• 卷创建验证由驱动本身处理
• 不需要考虑跨节点卷的限制

总结

通过这次改进，Incus项目中的LINSTOR驱动现在能够更准确地报告存储池的大小信息，为用户提供更直观的集群存储状况视图。这一改进不仅提升了用户体验，也为后续可能的存储管理功能奠定了基础。