Lee Duncan <[email protected]> writes: > On 12/9/19 10:20 AM, Gabriel Krisman Bertazi wrote: >> From: Bharath Ravi <[email protected]> >> >> Connection failure processing depends on a daemon being present to (at >> least) stop the connection and start recovery. This is a problem on a >> multipath scenario, where if the daemon failed for whatever reason, the >> SCSI path is never marked as down, multipath won't perform the >> failover and IO to the device will be forever waiting for that >> connection to come back. >> >> This patch implements an optional feature in the iscsi module, to >> perform the connection failure inside the kernel. This way, the >> failover can happen and pending IO can continue even if the daemon is >> dead. Once the daemon comes alive again, it can perform recovery >> procedures if applicable. > > > I don't suppose you've tested how this plays with the daemon, when present?
Hello, Yes, I did. It seemed to work properly over TCP. The stop calls are serialized by the rx_mutex, whoever gets it first, gets the job done. The second should return immediately since the socket is no longer there. What am I missing? -- Gabriel Krisman Bertazi -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/85h829l4xa.fsf%40collabora.com.
