Currently, next_reconnect indicates the next available time for reconnection, and its value increases as reconnection attempts fail, potentially reaching up to 30 seconds. However, if the client detects target recovery during this backoff period and tries to actively reconnect by calling the iscsi_reconnect or iscsi_force_reconnect interfaces, it cannot trigger a reconnection, because both interfaces are restricted by next_reconnect. If the time hasn’t reached next_reconnect, these interfaces won’t perform any action.
To address this issue, could we provide a method to reset next_reconnect or a forced reconnection method that bypasses the next_reconnect check to allow the client to proactively reconnect more quickly?
Currently, next_reconnect indicates the next available time for reconnection, and its value increases as reconnection attempts fail, potentially reaching up to 30 seconds. However, if the client detects target recovery during this backoff period and tries to actively reconnect by calling the
iscsi_reconnect
oriscsi_force_reconnect
interfaces, it cannot trigger a reconnection, because both interfaces are restricted by next_reconnect. If the time hasn’t reached next_reconnect, these interfaces won’t perform any action.To address this issue, could we provide a method to reset next_reconnect or a forced reconnection method that bypasses the next_reconnect check to allow the client to proactively reconnect more quickly?