[GH-ISSUE #344] StorageOperator::batchRead中,判断待读target是否upToDate时,是否有必要判断flat::PublicTargetState::SERVING #213

Closed
opened 2026-10-26 09:47:12 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @kaede11 on GitHub (Sep 30, 2025).
Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/344

storage节点failover后,local state达到UPTODATE后,会通过mgmtd广播public state(Serving)。
当前的upToDate实现如下所示:
`
bool upToDate() const {

 return localState == flat::LocalTargetState::UPTODATE && publicState == flat::PublicTargetState::SERVING;

}
`
查询请求到达已经是LocalTargetState::UPTODATE的storage时,会因为该storage节点还没收到mgmtd的广播,而拒绝请求,导致client侧延迟抖动。

由于client和storage获取routing info是有时间差的,所以upToDate中是否没必要再判断public state:

  1. client先收到的场景,代表待访问的storage节点已经是ready的
  2. client晚收到的场景,在选取routing target时,就不会选这个节点,因此也不会有问题
Originally created by @kaede11 on GitHub (Sep 30, 2025). Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/344 storage节点failover后,local state达到UPTODATE后,会通过mgmtd广播public state(Serving)。 当前的upToDate实现如下所示: ` bool upToDate() const { return localState == flat::LocalTargetState::UPTODATE && publicState == flat::PublicTargetState::SERVING; } ` 查询请求到达已经是LocalTargetState::UPTODATE的storage时,会因为该storage节点还没收到mgmtd的广播,而拒绝请求,导致client侧延迟抖动。 由于client和storage获取routing info是有时间差的,所以upToDate中是否没必要再判断public state: 1. client先收到的场景,代表待访问的storage节点已经是ready的 2. client晚收到的场景,在选取routing target时,就不会选这个节点,因此也不会有问题
Author
Owner

@SF-Zhou commented on GitHub (Oct 10, 2025):

确实是这样,我修复一下这个问题。

<!-- gh-comment-id:3388975257 --> @SF-Zhou commented on GitHub (Oct 10, 2025): 确实是这样,我修复一下这个问题。
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
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#213
No description provided.