deepseek-ai/3FS
1
0
Fork 0
mirror of https://github.com/deepseek-ai/3FS.git synced 2026-11-05 00:47:47 +00:00
Code Issues 166 Projects Packages Wiki Activity

[GH-ISSUE #268] CRAQ链式读过程中，storage_main进程故障会引起在读的客户端挂载目录挂掉的问题 #162

New issue
Open
opened 2026-10-26 09:46:19 +00:00 by bsakaguchi · 4 comments
bsakaguchi commented 2026-10-26 09:46:19 +00:00
Owner
Copy link

Originally created by @Berlin1999 on GitHub (May 7, 2025).
Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/268

【问题】
3FS为CRAQ链式读机制，测试读的时候，任意故障一个后端节点，客户端应该能正常读取，但目前测试发现，storage_main进程故障会引起在读的客户端挂载目录挂掉的问题

【环境情况】
2客户端（client1，client2）+2存储节点（storage1，storage2）

【前期环境确认】
在完成环境部署后，确认节点心跳正常，条带chains正常，所有的HEAD都分布在storage1-10001节点上，所有的TAIL都分布在storage2-10002节点上，状态均为正常

【测试前准备】
先在客户端预埋50G数据，fio下发正常，无error

【测试1】
停止stroage2的主进程（TAIL）
在fuseclient1对预埋的50G数据进行校验读，随后在读的过程中停止stroage2上面的主进程（systemctl stop storage_main），服务停止后IO有短暂的断流，随后恢复
查看list-chains，发现storage2的条带全都offline；查看list-targets，发现所有的TAIL状态都变为offline，符合正常预期；最后fuseclient1读校验正常结束，error=0，符合正常预期

随后恢复storage2节点，确认客户端读写正常，恢复至与初始环境状态一致

【测试2】
停止stroage1的主进程（HEAD）
在fuseclient1对预埋的50G数据进行校验读，随后在读的过程中停止stroage1上面的主进程（systemctl stop storage_main），服务停止后IO断流后无法恢复，当前客户端的挂载目录消失，hf3fs_fuse_main进程faild（core down）

查看list-chains，发现storage1的条带全都offline，storage2的状态为serving；查看list-targets，发现10001所在的Role变为TAIL，10002的Role变为HEAD；用fuseclient2客户端用同样的读校验命令，fio可正常读，最终error=0

不恢复storage1节点状态，重启fuseclient1的hf3fs_fuse_main进程，下发同样的fio，可正常读，最终error=0

Originally created by @Berlin1999 on GitHub (May 7, 2025). Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/268 【问题】 3FS为CRAQ链式读机制，测试读的时候，任意故障一个后端节点，客户端应该能正常读取，但目前测试发现，storage_main进程故障会引起在读的客户端挂载目录挂掉的问题 --------------------------------------------------------------------------------------------------------------------------------------------------- 【环境情况】 2客户端（client1，client2）+2存储节点（storage1，storage2） 【前期环境确认】 在完成环境部署后，确认节点心跳正常，条带chains正常，所有的HEAD都分布在storage1-10001节点上，所有的TAIL都分布在storage2-10002节点上，状态均为正常 【测试前准备】 先在客户端预埋50G数据，fio下发正常，无error 【测试1】 停止stroage2的主进程（TAIL） 在fuseclient1对预埋的50G数据进行校验读，随后在读的过程中停止stroage2上面的主进程（systemctl stop storage_main），服务停止后IO有短暂的断流，随后恢复 查看list-chains，发现storage2的条带全都offline；查看list-targets，发现所有的TAIL状态都变为offline，符合正常预期；最后fuseclient1读校验正常结束，error=0，符合正常预期 随后恢复storage2节点，确认客户端读写正常，恢复至与初始环境状态一致 --------------------------------------------------------------------------------------------------------------------------------------------------- 【测试2】 停止stroage1的主进程（HEAD） 在fuseclient1对预埋的50G数据进行校验读，随后在读的过程中停止stroage1上面的主进程（systemctl stop storage_main），服务停止后IO断流后无法恢复，当前客户端的挂载目录消失，hf3fs_fuse_main进程faild（core down） 查看list-chains，发现storage1的条带全都offline，storage2的状态为serving；查看list-targets，发现10001所在的Role变为TAIL，10002的Role变为HEAD；用fuseclient2客户端用同样的读校验命令，fio可正常读，最终error=0 不恢复storage1节点状态，重启fuseclient1的hf3fs_fuse_main进程，下发同样的fio，可正常读，最终error=0
bsakaguchi commented 2026-10-26 09:46:20 +00:00
Author
Owner
Copy link

@bugwz commented on GitHub (May 9, 2025):

很棒的测试👍

现在有没有解决该问题？有没有排查分析相关日志？位于 /var/log/3fs/ ，或者系统日志中有没有一些有价值的线索？

感觉像是在访问期间会持续访问同一个后端节点，而不是在后端节点通信异常后切换到其他节点。

<!-- gh-comment-id:2865919905 --> @bugwz commented on GitHub (May 9, 2025): 很棒的测试👍 现在有没有解决该问题？有没有排查分析相关日志？位于 /var/log/3fs/ ，或者系统日志中有没有一些有价值的线索？ 感觉像是在访问期间会持续访问同一个后端节点，而不是在后端节点通信异常后切换到其他节点。
bsakaguchi commented 2026-10-26 09:46:21 +00:00
Author
Owner
Copy link

@WANNA959 commented on GitHub (May 11, 2025):

请问是否测过持续写的情况下，按照storage节点维度，停止head/tail的故障表现呢

<!-- gh-comment-id:2869414162 --> @WANNA959 commented on GitHub (May 11, 2025): 请问是否测过持续写的情况下，按照storage节点维度，停止head/tail的故障表现呢
bsakaguchi commented 2026-10-26 09:46:21 +00:00
Author
Owner
Copy link

@Berlin1999 commented on GitHub (May 28, 2025):

很棒的测试👍

现在有没有解决该问题？有没有排查分析相关日志？位于 /var/log/3fs/ ，或者系统日志中有没有一些有价值的线索？

感觉像是在访问期间会持续访问同一个后端节点，而不是在后端节点通信异常后切换到其他节点。

是的，我们在日志中均没有观察到相关的有效的线索，在客户端日志只显示了rpc通信相关的日志。我们在新环境上均能稳定复现这个问题，但不能确定这个问题出在那里

<!-- gh-comment-id:2915212881 --> @Berlin1999 commented on GitHub (May 28, 2025): > 很棒的测试👍 > > 现在有没有解决该问题？有没有排查分析相关日志？位于 /var/log/3fs/ ，或者系统日志中有没有一些有价值的线索？ > > 感觉像是在访问期间会持续访问同一个后端节点，而不是在后端节点通信异常后切换到其他节点。 是的，我们在日志中均没有观察到相关的有效的线索，在客户端日志只显示了rpc通信相关的日志。我们在新环境上均能稳定复现这个问题，但不能确定这个问题出在那里
bsakaguchi commented 2026-10-26 09:46:22 +00:00
Author
Owner
Copy link

@Berlin1999 commented on GitHub (May 28, 2025):

请问是否测过持续写的情况下，按照storage节点维度，停止head/tail的故障表现呢

我们在持续写的时候，没有发现这个问题。停止head之后，很快就能看到全为tail的节点更新为head

<!-- gh-comment-id:2915520203 --> @Berlin1999 commented on GitHub (May 28, 2025): > 请问是否测过持续写的情况下，按照storage节点维度，停止head/tail的故障表现呢 我们在持续写的时候，没有发现这个问题。停止head之后，很快就能看到全为tail的节点更新为head
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
SF-Zhou-patch-1
No results found.
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/3FS#162
No description provided.