Chubaofs BlobStore日志级别优化：减少BlobDeleter冗余日志输出

在分布式存储系统Chubaofs的BlobStore组件中，Scheduler模块的BlobDeleter功能负责处理数据块的删除操作。在实际生产环境中，我们发现当BlobNode节点正在进行数据块(Chunk)压缩或迁移操作时，会产生大量重复的错误日志，给系统日志管理带来了不必要的压力。

问题背景

BlobNode节点在执行Chunk压缩或迁移操作时，会暂时将该Chunk标记为"只读"状态或"压缩中"状态。此时，任何针对该Chunk的修改操作（包括删除）都会被拒绝。在原有实现中，每次删除请求被拒绝时，系统都会记录一条ERROR级别的日志。

通过日志分析可以看到，在短时间内会产生数十万条类似以下的错误信息：

delete shard failed: bid[180098383], vuid[14894946582529], markDelete[true], code[628], err[chunk is compacting]
delete shard failed: bid[180605782], vuid[14890685169665], markDelete[true], code[628], err[chunk is compacting]

技术分析

在BlobNode的实现中，chunk.AllowModify()方法会检查当前Chunk是否允许修改操作。当检测到以下情况时会返回错误：

1. Chunk正在进行压缩操作且配置了DisableModifyInCompacting
2. Chunk处于只读状态(ReadOnly)
3. Chunk处于释放状态(Release)

这些状态变化是系统正常运行过程中的预期行为，特别是在后台进行数据压缩或迁移时。将这些情况记录为ERROR级别实际上会产生大量冗余日志，掩盖了真正需要关注的问题。

优化方案

经过分析，我们决定对这些预期内的"错误"进行日志级别调整：

1. 将"chunk is compacting"错误日志级别从ERROR降为WARN
2. 将"vuid readonly"错误日志级别从ERROR降为WARN

这种调整基于以下考虑：

• 这些状态是系统正常运行过程中的预期行为
• 操作失败后会由重试机制自动处理
• 降低日志级别后仍可追踪这些事件，但不会对日志系统造成过大压力
• 保留了真正异常情况的ERROR级别日志

实现细节

优化主要涉及BlobDeleter模块中对错误处理的日志级别调整。在收到来自BlobNode的特定错误码时，不再使用ERROR级别记录日志，而是改用WARN级别。同时保留了完整的错误上下文信息，包括BID(Blob ID)、VUID(Virtual Unit ID)等关键信息，确保在需要排查问题时仍能获取足够的信息。

预期效果

通过这项优化，我们预期能够：

1. 显著减少系统日志量，降低日志存储和分析的压力
2. 提高日志信号质量，使运维人员更容易发现真正需要关注的问题
3. 保持系统的可观测性，所有关键操作仍被记录
4. 不影响系统的正常功能和可靠性

这项优化特别适合大规模部署场景，能够有效降低系统的运维复杂度，同时保持对关键问题的及时发现能力。