Thanks for the response!!  I will thoroughly review the readme and
feedback any observations.

One question - how do I check whether the config parameter change has
been set correctly?  Do I just look at the config file in the
/etc/iscsi/nodes/.... etc..../default?  does not seem to show in
iscsiadm -m session -P <1, 2 or 3> level....

thanks again - I am running a script overnight to soak and see if any
networking hiccups would reproduce the symptoms now that I have
changed the timeout value ...

- a.

On 6/4/08, Mike Christie <[EMAIL PROTECTED]> wrote:
> a s p a s i a wrote:
>> Hello all,
>> I have been wondering a given scenario, where a server boots linux
>> over iscsiRoot;  how would iscsi initiator handle, if for instance,
>> access to the iscsiRoot device is interrupted for a second or two.  A
>> situation where this could possibly occur would be if one would add a
>> new target in the /etc/ietd.conf in the iscsi-target host, and then do
>> a restart, while certain hosts are booted against an iscsiRoot served
>> by that same target.
> This is what the replacement timeout is for. Section 8 in the README
> tries to describe how all those timers and scsi retries works. It is a
> little confusing, because some of the info on timeouts and retries is
> valuable for root and multipath but is only in the multipath section.
> Each scsi command gets 5 retries. If you were to disrupt iscsi service
> by pulling cables or restarting targets then if the scsi command's
> execution gets disrupted more than 5 times you will get a error to the FS.
> For each disruption you have replacement_timeout seconds to relogin to
> the target. If replacement_timeout expires then it does not matter how
> many scsi command retries you have left, the command will be failed and
> you will get an error to the FS.
> You really really want to use dm-multipath with iscsi. With dm-multipath
> there are lots of fun settings for if all paths should fail or look like
> they have failed (for example if you reboot the target or pull cables).
>> Any thoughts?
>> Have there been any past discussions on this or any papers/techtips
>> that may address this kind of situation?
> It has been discussed a lot on the list and that is why I tried to
> comment on it in the README. If you could read that and give me some
> feedback so it is more useful for others in the future it would be helpful.
> >

. . . . . . . . . . ..

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

Reply via email to