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
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
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at