mirror of
https://github.com/deepseek-ai/3FS.git
synced 2026-11-05 00:47:47 +00:00
[GH-ISSUE #238] 能帮忙看下 storage 运行中 panic 的原因吗？ #146
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
deepseek-ai/3FS#146
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jojomanar on GitHub (Apr 11, 2025).
Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/238
panic 时的日志：
对应代码位置：
初步怀疑是这里的并发控制有问题，但是没有找到哪里的代码有问题，请问线上有遇到过吗？
@SF-Zhou commented on GitHub (Apr 11, 2025):
当前版本的代码在线上没有遇到该问题，可以分享下出现该问题时具体的场景吗？
@jojomanar commented on GitHub (Apr 16, 2025):
正常运行中 panic 的，没有做特殊操作，今天又遇到了 2 个存储进程先后 panic
@jojomanar commented on GitHub (Apr 16, 2025):
方便微信沟通下吗？
我的微信：ao212111
@SF-Zhou commented on GitHub (Apr 17, 2025):
我们没有遇到类似的问题，线上也没有其他人反映过类似的问题。
你可以分享下你的软硬件环境、硬盘类型、文件系统、运行时可能有哪些读写操作等信息。
@YuqqiZhou commented on GitHub (Apr 22, 2025):
我们进一步分析环境之后，发现当时有removeTarget的动作，之后我们发现了removeTarget有可能导致元数据不一致的问题，这最终导致了panic，对应的MR是 https://github.com/deepseek-ai/3FS/pull/252 。在我们改动了代码之后，没有再现该问题。
@SF-Zhou commented on GitHub (Apr 22, 2025):
这个修改并不能解决问题。删除的顺序必须是先
meta_store.remove，再meta_cache.remove，否所中间可能出现读操作将chunk meta重新加载回来，会导致不一致的情况。真正需要的修改是禁止在 target 正常使用过程中调用RemoveTarget，在 3FS 开源的代码中并不会出现这种情况，我们一定保证只有在 target 处理完所有请求、处于离线状态下才允许删除。你的 PR 将会被关闭。This modification does not resolve the issue. The deletion sequence must be
meta_store.removefirst, followed bymeta_cache.remove. Otherwise, intermediate read operations might reload thechunk meta, leading to inconsistencies. The actual required fix is to prohibit invokingRemoveTargetduring the normal operation of the target. In the 3FS open-source code, this scenario does not occur, as we strictly ensure deletion is permitted only after the target has processed all requests and is in an offline state. Your PR will be closed.@YuqqiZhou commented on GitHub (Apr 22, 2025):
你好，我还是认为目前的代码在线上环境可能还是有问题，请再看看batch remove的流程
1.self.meta_store.remove_mut ，这一过程并不会写rocksdb
2.删meta_cache 释放 chunk pos
3.再meta_store.write （攒够1MB）
而你说的 meta_store.remove 的实现是
self.remove_mut(chunk_id, chunk_meta, &mut write_batch)?;
self.write(write_batch, sync)
1和3步都完成。后再进行 meta_cache.remove。132这个逻辑在 commit_chunk 中 if chunk.is_remove 的分支有体现，保证了不出现 “中间可能出现读操作将 chunk meta 重新加载回来，会导致不一致的情况。” 我的修改正是把batch remove的逻辑改为该逻辑。另外，想顺便询问一下，“我们一定保证只有在 target 处理完所有请求、处于离线状态下才允许删除” 具体包括什么措施呢？通过 list-target观察到offline 可以吗》
@YuqqiZhou commented on GitHub (Apr 22, 2025):
现在线上的代码，如果一个SSD上 ，target1 在remove，target2在读写，应该能触发pos元数据不一致的情况，只看target1上有没有inflight请求并不足够
@SF-Zhou commented on GitHub (Apr 23, 2025):
在进一步分析你的修改后，我发现你的方案是对的，原先的代码确实有不一致的情况。感谢。
After further analyzing your modifications, I realized that your approach was correct—there were indeed inconsistencies in the original code. Thank you.