问题背景

我们自研的一款文件上传中间件，用于使用统一的上传协议支持客户端将文件上传到s3/ceph/mfs/oss/obs/minio等文件系统。其中一个很大的亮点，就是云原生的架构设计，对于上传文件到公司内部自己搭建的moosefs、cephfs文件系统，不再需要通过挂盘写，而是通过api操作将计算与存储分离。为了实现这一目标，费了很大劲。

由于moosefs没有关于底层自定义二进制通信协议的文档，且各大版本api上差异很大，幸运的是，我们在github上找到一个go语言实现api操作moosefs的开源库，但不幸的是，这个组件实现的api版本很低，并且调研阶段写demo的过程中就发现很多bug。但为了实现去挂盘提升稳定性的目标，也尝试去看moosefs的源码，从源码中抠出协议（新旧版本差异的地方），终于moosefs-client-go组件开发完成。

在测试阶段，我们发现通过这个中间件上传文件到moosefs后，moosefs上存储的文件的md5与本地原文件md5不一致，如果是图片，能很明显的看出少了一块像素。

MooseFS文件系统简介

简单介绍一下moosefs（mfs）文件系统，便于理解后续内容。

moosefs架构中的两个重要角色（moosefs-client-go需要实现与这两个角色交互）：

• Master Server：管理服务，负责管理各个数据存储服务（Chunk Server），调度文件读写，回收文件空间以及恢复多节点拷贝。MFS只支持一个master节点，这是一个单点故障，也是moosefs架构的缺陷。
• Chunk Server：数据存储服务，是真正存储用户数据的服务，主动连接Master Server，听从Master Server调度，提供存储空间，为客户端提供数据传输。

mosefs将一个文件分成多个chunk(块)存储，一个chunk又分成多个block(段/小块)，一个chunk的大小是64m，一个block的大小是65536字节。一个文件分多少个chunk存储，上传就需要写多少个chunk，一般上传的文件都很小，只需要写一个chunk。

上传过程先是通过master调度创建chunk，master返回chunk所在的chunk server节点（包括副本所在节点）， 可从返回的chunk server节点中选择其中一个节点读/写chunk，写chunk时需要带上chunk所有节点信息，用于chunk server当前节点同步复制给其它chunk server节点。

写数据到Chunk Server以及副本同步的流程如下图所示。

文件上传后MD5不一致Bug原因分析

在测试阶段，我们通过调小数据包后发现没有再复现，但实际并没有修复问题，只是将概率调小了，所以很难再复现。

后面由于测试环境换了个mfs集群做测试，chunk server节点数比较多，配置的文件副本数是3， 而早期使用的moosefs集群，配置的文件副本数是1，也就是不需要copy。所以出现的概率比之前大了，很容易复现。 当文件副本数是3的时候，通过观察下载日记发现，多次下载每次下载的文件md5都是不一致的。

通过写测试用例分别从3个节点读某个出问题的文件，发现有一个节点的文件md5是正确的，另外两个是错误的（这是很关键的一步发现），说明是上传的问题。但通过抓包分析发送出去的数据包未发现问题，可以确定是发生在moosefs的内部逻辑， 只能是寄希望通过看moosefs的c++源码能够发现问题。

与chunk server交互传输数据的顺序是：

• 1.先发送CUTOCS_WRITE命令初始化写；
• 2.再循环（如果需要分多个block存储，或一个block需要分多次写）发送CUTOCS_WRITE_DATA命令写数据（传数据），每一次发送CUTOCS_WRITE_DATA命令都需要等待chunk server回复CSTOCL_WRITE_STATUS；
• 3.最后再发送CLTOCS_WRITE_FINISH命令释放资源。

如果是发送CUTOCS_WRITE命令后的第一次写（CUTOCS_WRITE_DATA），moosefs会响应两次cmd=CSTOCL_WRITE_STATUS的数据包，如果wid=0（wid=写ID,可以理解为请求ID），说明后面还有一个数据包待接收。 （这是非常关键的一步发现）

开源组件漏了这一步（可能是BUG，也可能是版本差异），也就是没等待第二次真正的写成功的响应，就继续发送CLTOCS_WRITE_FINISH完成命令了。 由于CLTOCS_WRITE_FINISH无响应，不需要读响应，所以很难发现还有数据包未被接收。

因为写完成命令会中断过程释放资源，猜测是提前中断释放资源导致没写完、以及副本没copy完（例如，需要拷贝到另外两个节点，只完成了其中一个节点的拷贝，还有一个节点未拷贝）。

这样猜测的原因是，当我尝试重试写一次的时候，发现没问题了，因为在等待重试的响应时，接收到了wid等于前一次的wid（实际是前一次的响应，但以为是重试后的响应）， 此时才会发送CLTOCS_WRITE_FINISH完成命令。 （这也是为什么循环多次写的时候，发现第一次写返回的wid是0，而后面每次写返回的wid都是小1的（一期排查过期中发现的））

一期通过调小数据包后没复现，是因为一次写的数据小了，写数据快了，并且副本数是1不需要copy，中断过程之前就完成写，所以概率变得非常小，200的并发，才没有再复现。

总结

这Bug难在对mfs通信协议的不了解，以及工作原理的不理解。在不了解协议的情况下，抓包分析只能看我们传给mfs的数据有没有问题，并且由于是二进制协议，不是简单的请求响应，很难想到发一条命令会有两次响应。而在不了解内部逻辑的情况下，也不知道不等待响应后再调用结束命令会发生什么。moosefs官方不提供sdk，是因为推荐使用挂盘的方式使用，所以也不会有协议文档。

在发现关键现象时，通过猜测+证实的方式去探测结论能够快速发现找到问题，而所有猜测都被结论否定时，就需要花时间耐心的学习研究底层逻辑，可能无法从中直接发现问题，但能提供更多排查问题的思路。