Eddy Quicksall wrote:
> Is there a case where the iscsi layer will generate a SCSI TMF? If so, what
> are the cases?

Every scsi command has a timer set on it. The value of the timer is 
normally 60 seconds. You can see the value for each device here:
That is RW, so you can echo to it to change the value or you can edit 
the udev rule for it (see the README for defaults on that).

If the command does not complete within the command timeout, the scsi 
layer will fire its error handler. The scsi eh will first ask the iscsi 
layer if it wants more time.

In recent kernels (2.6.25 and above or if using the open-iscsi.org 
modules with older kernels), the iscsi layer will only ask for more time 
if we want to send a nop to check if the target is there and responding 
(we will send a nop if we have not got any traffic for 
node.conn[0].timeo.noop_out_interval seconds). We do this because the 
scsi eh is very slow and has issues, and we only want to run it if we 
really have to.

If it turns out that the connection is good, we let the scsi eh do its 
thing. It will first stop all new IO from being sent to the driver. Then 
it will try to abort the outstanding tasks by calling the iscsi layer 
abort callout which we send a abort task for. If the abort does not 
complete within node.session.err_timeo.abort_timeout, we assume the 
connection may be bad and just drop the session and try to relogin. If 
the abort failed, then we will try a lun reset. If that fails or 
timesout (node.session.err_timeo.lu_reset_timeout), we will drop the 
session and try to relogin. There are patches floating around to try a 
warm target reset after the lun reset, but they had issues with some 
targets and is not merged.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to