On 04/15/2011 01:43 PM, Ben Greear wrote:
On 04/15/2011 11:37 AM, Mike Christie wrote:
On 04/15/2011 01:18 PM, Mike Christie wrote:

Ok, yeah we have seen this type of setup before and we should be able to
handle this situation as long as the other controller assumes the IP and
is ready within node.session.timeo.replacement_timeout seconds.

What is expected behaviour if it *does NOT* become ready by the timeout

In /var/log/messsages you would see the message:

session recovery timed out after %d secs

then see exactly what you are seeing. iSCSI layers fails to the scsi layer scsi layer prints DID_TRANSPORT_FAILFAST errors: sd 11:0:0:3: [sdk] Result: hostbyte=DID_TRANSPORT_FAILFAST driverbyte=DRIVER_OK

then see request errors from lower part of block layer:
end_request: I/O error, dev sdk, sector 0

then see buffer io errors:
Buffer I/O error on device sdk, logical block 0

then see filesystem errors.

What is the value of

iscsiadm -m node -T yourtarget | grep

Oh yeah, to inrease that for targets you have already discovered do:

iscsidm -m node -T yourtarget -o update -n
node.session.timeo.replacement_timeout -v your_value_in_seconds

or to make it your default set it in iscsid.conf:
node.session.timeo.replacement_timeout = your_value_in_seconds

then when you discover new targets they will get the iscsid.conf value.

They are likely set at the default value, whatever that is..but I'll

Also, even if we fail the time-out, I assume the system shouldn't hang
and panic as it did?

It will for ext3. I believe there is a option for to panic on errors or not.

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 
For more options, visit this group at 

Reply via email to