Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

srp_reconnect_rport(9) [centos man page]

SRP_RECONNECT_RPORT(9)						  SCSI mid layer					    SRP_RECONNECT_RPORT(9)

NAME
srp_reconnect_rport - reconnect to an SRP target port SYNOPSIS
int srp_reconnect_rport(struct srp_rport * rport); ARGUMENTS
rport -- undescribed -- DESCRIPTION
Blocks SCSI command queueing before invoking reconnect such that queuecommand won't be invoked concurrently with reconnect from outside the SCSI EH. This is important since a reconnect implementation may reallocate resources needed by queuecommand. NOTES
- This function neither waits until outstanding requests have finished nor tries to abort these. It is the responsibility of the reconnect function to finish outstanding commands before reconnecting to the target port. - It is the responsibility of the caller to ensure that the resources reallocated by the reconnect function won't be used while this function is in progress. One possible strategy is to invoke this function from the context of the SCSI EH thread only. Another possible strategy is to lock the rport mutex inside each SCSI LLD callback that can be invoked by the SCSI EH (the scsi_host_template.eh_*() functions and also the scsi_host_template.queuecommand function). AUTHORS
James Bottomley <James.Bottomley@hansenpartnership.com> Author. Rob Landley <rob@landley.net> Author. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 SRP_RECONNECT_RPORT(9)

Check Out this Related Man Page

FC_REMOTE_PORT_DELET(9) 					  SCSI mid layer					   FC_REMOTE_PORT_DELET(9)

NAME
fc_remote_port_delete - notifies the fc transport that a remote port is no longer in existence. SYNOPSIS
void fc_remote_port_delete(struct fc_rport * rport); ARGUMENTS
rport The remote port that no longer exists DESCRIPTION
The LLDD calls this routine to notify the transport that a remote port is no longer part of the topology. Note: Although a port may no longer be part of the topology, it may persist in the remote ports displayed by the fc_host. We do this under 2 conditions: 1) If the port was a scsi target, we delay its deletion by "blocking" it. This allows the port to temporarily disappear, then reappear without disrupting the SCSI device tree attached to it. During the "blocked" period the port will still exist. 2) If the port was a scsi target and disappears for longer than we expect, we'll delete the port and the tear down the SCSI device tree attached to it. However, we want to semi-persist the target id assigned to that port if it eventually does exist. The port structure will remain (although with minimal information) so that the target id bindings remails. If the remote port is not an FCP Target, it will be fully torn down and deallocated, including the fc_remote_port class device. If the remote port is an FCP Target, the port will be placed in a temporary blocked state. From the LLDD's perspective, the rport no longer exists. From the SCSI midlayer's perspective, the SCSI target exists, but all sdevs on it are blocked from further I/O. The following is then expected. If the remote port does not return (signaled by a LLDD call to fc_remote_port_add) within the dev_loss_tmo timeout, then the scsi target is removed - killing all outstanding i/o and removing the scsi devices attached ot it. The port structure will be marked Not Present and be partially cleared, leaving only enough information to recognize the remote port relative to the scsi target id binding if it later appears. The port will remain as long as there is a valid binding (e.g. until the user changes the binding type or unloads the scsi host with the binding). If the remote port returns within the dev_loss_tmo value (and matches according to the target id binding type), the port structure will be reused. If it is no longer a SCSI target, the target will be torn down. If it continues to be a SCSI target, then the target will be unblocked (allowing i/o to be resumed), and a scan will be activated to ensure that all luns are detected. Called from normal process context only - cannot be called from interrupt. NOTES
This routine assumes no locks are held on entry. AUTHORS
James Bottomley <James.Bottomley@hansenpartnership.com> Author. Rob Landley <rob@landley.net> Author. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 FC_REMOTE_PORT_DELET(9)
Man Page