admin_cli 会在不进行优雅关闭的情况下销毁存储 RDMA QP,导致服务器端遗失 QP,从而在之后出现 WRType::CHECK 错误。
作者: liaoyunkun创建于 2026年8月27日更新于 2026年9月13日
- 3FS 代码路径:与上游
main提交22fca04564c7cc230fd8b9523b8b92864e1dad47相同,涉及以下文件。 - 传输:RC RDMA。
- 拓扑:一个管理节点和五个存储服务。
- 触发:一个短暂的
admin_cli create-target调用,访问了一个已存在的目标。为了隔离重现,不需要 fio 或存储数据负载。 - 以下使用的附加日志字段仅用于可观察性;它们不会改变关闭、检查、QP 或重试行为。
- 一个部署命令先连接到 storage1，然后连接到 storage5，最后退出。每个存储侧 QP 变为准备状态后大约 1783.5 秒，所有五个 QP 在 0.47 毫秒窗口内报告了相同的第一个完成错误：
| 存储 | 存储 QPN | admin_cli 对端 QPN |
从准备状态到第一个故障 |
|---|---|---|---|
| storage1 | 41 | 217 | 1783.754361 秒 |
| storage2 | 38 | 218 | 1783.565653 秒 |
| storage3 | 38 | 219 | 1783.838937 秒 |
| storage4 | 38 | 220 | 1783.650263 秒 |
| storage5 | 38 | 221 | 1783.461406 秒 |
每个 QP 的第一个完成具有以下字段：
state=READY
closed=false
wc_status=transport retry counter exceeded
wc_opcode=IBV_WC_RDMA_WRITE
wr=[WRType::CHECK]
vendor_err=8
byte_len=0这些 QP 由 admin_cli 在数据负载开始之前建立;它们不是应用程序数据 QP。
- 我们随后运行了一个 idempotent
create-target命令，对一个现有目标进行操作，没有运行 fio 进程，并记录了 QP 端点和进程生命周期：
21:30:10.015409 storage: acceptor local_qpn=56 peer_qpn=297 READY
21:30:10.015543 admin_cli PID 192794: initiator local_qpn=297 peer_qpn=56 READY
21:30:10.017792 admin_cli: IBSocketManager::stopAndJoin 启动
21:30:10.018022 admin_cli: StorageClient stop 之后开始
21:30:10.018402 admin QPN297 销毁开始: state=READY closed=false first_fault=false
21:30:10.018697 admin
…内容来源: deepseek-ai/3FS