[GH-ISSUE #240] storage节点是否需要全部使用一致的端口？

bsakaguchi commented

2026-10-26 09:45:59 +00:00

Owner

Originally created by @GreatStone on GitHub (Apr 14, 2025).
Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/240

在某些分布式容器环境下，可能无法给所有容器分配一致的端口，比如8000（可能被自同机的其他实例占用），这个能否通过某些方法解决，或者保持所有node端口一致是否有其他重要的考量？

Originally created by @GreatStone on GitHub (Apr 14, 2025). Original GitHub issue: https://github.com/deepseek-ai/3FS/issues/240 在某些分布式容器环境下，可能无法给所有容器分配一致的端口，比如8000（可能被自同机的其他实例占用），这个能否通过某些方法解决，或者保持所有node端口一致是否有其他重要的考量？

bsakaguchi closed this issue

2026-10-26 09:45:59 +00:00

bsakaguchi commented

2026-10-26 09:45:59 +00:00

Author

Owner

@SF-Zhou commented on GitHub (Apr 14, 2025):

No need to use the same port.

@SF-Zhou commented on GitHub (Apr 14, 2025): No need to use the same port.

bsakaguchi commented

2026-10-26 09:45:59 +00:00

Author

Owner

@GreatStone commented on GitHub (Apr 14, 2025):

No need to use the same port.

感谢回复，最近部署服务时发现端口问题报错，我再详细排查一下，如果有其他疑问再来请教

@GreatStone commented on GitHub (Apr 14, 2025): > No need to use the same port. 感谢回复，最近部署服务时发现端口问题报错，我再详细排查一下，如果有其他疑问再来请教

bsakaguchi commented

2026-10-26 09:45:59 +00:00

Author

Owner

@GreatStone commented on GitHub (Apr 15, 2025):

重新部署复现了一次，按照文档（https://github.com/deepseek-ai/3FS/blob/main/deploy/README.md）进行部署，部署3个storage节点，并将其中一个storage节点的端口修改到和另外两个不同(node1=8050, node2 = 8050, node3 = 8055)。
fuse挂载后读写没有问题，但是在修改了端口的实例上面发现错误日志：
ConfigManager.cc:84 WARNING] Update config failed at updating: ConfigUpdateFailed(17) Not support hot update: server.base.groups#0.listener.listen_port. desc: ConfigVersion(3)

@SF-Zhou 请帮忙确认下是否有问题？

@GreatStone commented on GitHub (Apr 15, 2025): 重新部署复现了一次，按照文档（https://github.com/deepseek-ai/3FS/blob/main/deploy/README.md）进行部署，部署3个storage节点，并将其中一个storage节点的端口修改到和另外两个不同(node1=8050, node2 = 8050, node3 = 8055)。 fuse挂载后读写没有问题，但是在修改了端口的实例上面发现错误日志： ConfigManager.cc:84 WARNING] Update config failed at updating: ConfigUpdateFailed(17) Not support hot update: server.base.groups#0.listener.listen_port. desc: ConfigVersion(3) @SF-Zhou 请帮忙确认下是否有问题？

bsakaguchi commented

2026-10-26 09:46:00 +00:00

Author

Owner

@SF-Zhou commented on GitHub (Apr 15, 2025):

造成该现象的原因较为复杂。Storage 的配置是通过 Mgmtd 下发的，已经启动的实例如果发现最新的配置中 listen_port 发生了修改，是会拒绝接受最新配置的，并打印错误日志（因为对已经启动的实例修改端口没有意义）。当然这并不影响 Storage 的运行。在我们线上实际处理中，下发的配置实际上会是模板，由 Storage 自己 render 后再加载配置，进而可以实现在同一套配置方案实现不同的配置项，但这部分代码并没有开源。对于你的问题，可以考虑将 listen_port 配置为 0，由进程自己找到可用的端口（但我自己没有尝试过）。或者使用没有被其他进程使用的端口区间。

The reasons for this phenomenon are relatively complex. The configuration of Storage is delivered through Mgmtd. If a running instance detects that the listen_port in the latest configuration has been modified, it will refuse to accept the new configuration and log an error (since changing the port for an already running instance is meaningless). However, this does not affect the operation of Storage. In our actual online handling, the delivered configurations are essentially templates. Storage renders and then loads the configurations itself, enabling different configurations under the same template. However, this part of the code is not open-sourced. For your issue, you could consider setting listen_port to 0, allowing the process to automatically find an available port (though I haven’t tested this myself). Alternatively, use a port range that is not occupied by other processes.

@SF-Zhou commented on GitHub (Apr 15, 2025): 造成该现象的原因较为复杂。Storage 的配置是通过 Mgmtd 下发的，已经启动的实例如果发现最新的配置中 `listen_port` 发生了修改，是会拒绝接受最新配置的，并打印错误日志（因为对已经启动的实例修改端口没有意义）。当然这并不影响 Storage 的运行。在我们线上实际处理中，下发的配置实际上会是模板，[由 Storage 自己 render 后再加载配置](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/src/common/utils/RenderConfig.cc#L71)，进而可以实现在同一套配置方案实现不同的配置项，但这部分代码并没有开源。对于你的问题，可以考虑将 `listen_port` 配置为 0，由进程自己找到可用的端口（但我自己没有尝试过）。或者使用没有被其他进程使用的端口区间。 The reasons for this phenomenon are relatively complex. The configuration of Storage is delivered through Mgmtd. If a running instance detects that the listen_port in the latest configuration has been modified, it will refuse to accept the new configuration and log an error (since changing the port for an already running instance is meaningless). However, this does not affect the operation of Storage. In our actual online handling, the delivered configurations are essentially templates. [Storage renders and then loads the configurations itself](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/src/common/utils/RenderConfig.cc#L71), enabling different configurations under the same template. However, this part of the code is not open-sourced. For your issue, you could consider setting listen_port to 0, allowing the process to automatically find an available port (though I haven’t tested this myself). Alternatively, use a port range that is not occupied by other processes.

bsakaguchi commented

2026-10-26 09:46:00 +00:00

Author

Owner

@GreatStone commented on GitHub (Apr 15, 2025):

造成该现象的原因较为复杂。Storage 的配置是通过 Mgmtd 下发的，已经启动的实例如果发现最新的配置中 listen_port 发生了修改，是会拒绝接受最新配置的，并打印错误日志（因为对已经启动的实例修改端口没有意义）。当然这并不影响 Storage 的运行。在我们线上实际处理中，下发的配置实际上会是模板，由 Storage 自己 render 后再加载配置，进而可以实现在同一套配置方案实现不同的配置项，但这部分代码并没有开源。对于你的问题，可以考虑将 listen_port 配置为 0，由进程自己找到可用的端口（但我自己没有尝试过）。或者使用没有被其他进程使用的端口区间。

The reasons for this phenomenon are relatively complex. The configuration of Storage is delivered through Mgmtd. If a running instance detects that the listen_port in the latest configuration has been modified, it will refuse to accept the new configuration and log an error (since changing the port for an already running instance is meaningless). However, this does not affect the operation of Storage. In our actual online handling, the delivered configurations are essentially templates. Storage renders and then loads the configurations itself, enabling different configurations under the same template. However, this part of the code is not open-sourced. For your issue, you could consider setting listen_port to 0, allowing the process to automatically find an available port (though I haven’t tested this myself). Alternatively, use a port range that is not occupied by other processes.

有两个问题想要确认一下：

这个错误日志是否不影响storage的运行，并且这个storage节点也能正常的对外提供服务
如果我通过外围手段（比如启动脚本）在启动时指定了一个监听端口，是否也是可以的

@GreatStone commented on GitHub (Apr 15, 2025): > 造成该现象的原因较为复杂。Storage 的配置是通过 Mgmtd 下发的，已经启动的实例如果发现最新的配置中 `listen_port` 发生了修改，是会拒绝接受最新配置的，并打印错误日志（因为对已经启动的实例修改端口没有意义）。当然这并不影响 Storage 的运行。在我们线上实际处理中，下发的配置实际上会是模板，[由 Storage 自己 render 后再加载配置](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/src/common/utils/RenderConfig.cc#L71)，进而可以实现在同一套配置方案实现不同的配置项，但这部分代码并没有开源。对于你的问题，可以考虑将 `listen_port` 配置为 0，由进程自己找到可用的端口（但我自己没有尝试过）。或者使用没有被其他进程使用的端口区间。 > > The reasons for this phenomenon are relatively complex. The configuration of Storage is delivered through Mgmtd. If a running instance detects that the listen_port in the latest configuration has been modified, it will refuse to accept the new configuration and log an error (since changing the port for an already running instance is meaningless). However, this does not affect the operation of Storage. In our actual online handling, the delivered configurations are essentially templates. [Storage renders and then loads the configurations itself](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/src/common/utils/RenderConfig.cc#L71), enabling different configurations under the same template. However, this part of the code is not open-sourced. For your issue, you could consider setting listen_port to 0, allowing the process to automatically find an available port (though I haven’t tested this myself). Alternatively, use a port range that is not occupied by other processes. 有两个问题想要确认一下： 1. 这个错误日志是否不影响storage的运行，并且这个storage节点也能正常的对外提供服务 2. 如果我通过外围手段（比如启动脚本）在启动时指定了一个监听端口，是否也是可以的

bsakaguchi commented

2026-10-26 09:46:00 +00:00

Author

Owner

@SF-Zhou commented on GitHub (Apr 15, 2025):

造成该现象的原因较为复杂。Storage 的配置是通过 Mgmtd 下发的，已经启动的实例如果发现最新的配置中 listen_port 发生了修改，是会拒绝接受最新配置的，并打印错误日志（因为对已经启动的实例修改端口没有意义）。当然这并不影响 Storage 的运行。在我们线上实际处理中，下发的配置实际上会是模板，由 Storage 自己 render 后再加载配置，进而可以实现在同一套配置方案实现不同的配置项，但这部分代码并没有开源。对于你的问题，可以考虑将 listen_port 配置为 0，由进程自己找到可用的端口（但我自己没有尝试过）。或者使用没有被其他进程使用的端口区间。
The reasons for this phenomenon are relatively complex. The configuration of Storage is delivered through Mgmtd. If a running instance detects that the listen_port in the latest configuration has been modified, it will refuse to accept the new configuration and log an error (since changing the port for an already running instance is meaningless). However, this does not affect the operation of Storage. In our actual online handling, the delivered configurations are essentially templates. Storage renders and then loads the configurations itself, enabling different configurations under the same template. However, this part of the code is not open-sourced. For your issue, you could consider setting listen_port to 0, allowing the process to automatically find an available port (though I haven’t tested this myself). Alternatively, use a port range that is not occupied by other processes.

有两个问题想要确认一下：
1. 这个错误日志是否不影响storage的运行，并且这个storage节点也能正常的对外提供服务

2. 如果我通过外围手段（比如启动脚本）在启动时指定了一个监听端口，是否也是可以的

该错误日志不会影响 Storage 的运行，但是会影响 Storage 接收 Mgmtd 侧后续下发的动态配置修改（如果你不需要该功能就不受影响）。
我不确定还有没有其他办法去指定监听的端口。你可以试一试。

This error log does not affect the operation of Storage, but it may impact Storage's ability to receive subsequent dynamic configuration modifications issued from the Mgmtd side (if you don't require this functionality, it won't affect you).
I'm not sure if there are alternative methods to specify the listening port. You can give it a try.

@SF-Zhou commented on GitHub (Apr 15, 2025): > > 造成该现象的原因较为复杂。Storage 的配置是通过 Mgmtd 下发的，已经启动的实例如果发现最新的配置中 `listen_port` 发生了修改，是会拒绝接受最新配置的，并打印错误日志（因为对已经启动的实例修改端口没有意义）。当然这并不影响 Storage 的运行。在我们线上实际处理中，下发的配置实际上会是模板，[由 Storage 自己 render 后再加载配置](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/src/common/utils/RenderConfig.cc#L71)，进而可以实现在同一套配置方案实现不同的配置项，但这部分代码并没有开源。对于你的问题，可以考虑将 `listen_port` 配置为 0，由进程自己找到可用的端口（但我自己没有尝试过）。或者使用没有被其他进程使用的端口区间。 > > The reasons for this phenomenon are relatively complex. The configuration of Storage is delivered through Mgmtd. If a running instance detects that the listen_port in the latest configuration has been modified, it will refuse to accept the new configuration and log an error (since changing the port for an already running instance is meaningless). However, this does not affect the operation of Storage. In our actual online handling, the delivered configurations are essentially templates. [Storage renders and then loads the configurations itself](https://github.com/deepseek-ai/3FS/blob/ee9a5cee0a85c64f4797bf380257350ca1becd36/src/common/utils/RenderConfig.cc#L71), enabling different configurations under the same template. However, this part of the code is not open-sourced. For your issue, you could consider setting listen_port to 0, allowing the process to automatically find an available port (though I haven’t tested this myself). Alternatively, use a port range that is not occupied by other processes. > > 有两个问题想要确认一下： > > 1. 这个错误日志是否不影响storage的运行，并且这个storage节点也能正常的对外提供服务 > > 2. 如果我通过外围手段（比如启动脚本）在启动时指定了一个监听端口，是否也是可以的 1. 该错误日志不会影响 Storage 的运行，但是会影响 Storage 接收 Mgmtd 侧后续下发的动态配置修改（如果你不需要该功能就不受影响）。 2. 我不确定还有没有其他办法去指定监听的端口。你可以试一试。 --- 1. This error log does not affect the operation of Storage, but it may impact Storage's ability to receive subsequent dynamic configuration modifications issued from the Mgmtd side (if you don't require this functionality, it won't affect you). 2. I'm not sure if there are alternative methods to specify the listening port. You can give it a try.

Rows
Columns

[GH-ISSUE #240] storage节点是否需要全部使用一致的端口？ #150