Hi Roland, I'm sending 4 patches that implement kernel support for removal and restoration of a target (will be used by ibsrpdm).
Some comments about them 1) The first patch splits reconnect to 2 two functions: _srp_remove_target and _srp_restore_target. _srp_remove_target uses the functions I sent in previous patch (Misc cleanups in ib_srp). If you want I can resend this patch without using the previous patch (But then there will be a problem with the previous patch :( ). 2) These patches implement the following behavior: When someone writes the string "remove" to /sys/class/scsi_host/host?/remove_target the corresponding target goes to a DISCONNECTED state (After closing the cm, and reset all pending requests). Now when the scsi performs queuecommand to this host a SCSI_MLQUEUE_HOST_BUSY is returned. These causes the scsi layer to wait until the target turns to LIVE state. This is very nice if the user that initiated the remove_target knows what he is doing and will perform a restore_target later. On the other hand it may be problematic if the target remains DISCONNECTED and user applications that try to access this target remain stuck in the kernel (in the scsi layer) I've several ideas on how to handle it (have a timeout after which queuecommand will return fail, try to perform a restore_target after a timeout, make sure the daemon will run a restore_target after a timeout) but I'm not sure they are the correct thing to do. I'm waiting for suggestions. In any case I believe we should apply these patches and add solution to this problem later. Please comment. -- Ishai Rabinovitz _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general