On Thursday, October 4, 2018 at 10:20:56 AM UTC-7, Sai Chaitanya Mitta 
wrote:
>
>
>
> On Wednesday, 14 April 2010 01:33:13 UTC+5:30, Mike Christie wrote:
>>
>> On 04/13/2010 03:23 AM, Christian Iversen wrote:
>> > Hi iSCSI guys
>> >
>> > I've set up iSCSI storage on our servers, using IETD and OpenISCSI.
>> >
>> > It works and performs great, but I am a little unsure of how to adjust
>> > the timeout values properly.
>> >
>> > On our storage servers, we use heartbeat to achieve HA failover, which
>> > works nicely. However, the client machines only try for a fixed amount
>> > of time before giving up, so if the failover for some reason does not
>> > happen relatively quickly, everything grinds to a halt in a really bad 
>> way.
>> >
>> > I would like to set up open-iscsi to keep trying, preferably at low
>> > intervals, and not give up contacting the server.
>> >
>> > There are quite a few different timeouts, and I have been unable to find
>> > any sort of reference documentation for this. Maybe someone here can 
>> help?
>> >
>>
>> Did you read the README? I tried to document the timeouts that are asked 
>> about most frequently on the list.
>>
>>
>> > What I'd like is the following:
>> >
>> > - Never give up trying (or at least try for a month :)
>>
>> The iscsi initiator almost always tries to reconnect to the target. If 
>> it gets a successful login then that fails it will try to relogin until 
>> the the user runs some iscsiadm command to logout.
>>
>> If you mean you want it to hold onto IO and not fail it, then you want 
>> the replacement_timeout/recovery_timeout. There should be info in the 
>> README and iscsid.conf about this. If it is not clear let me know.
>>
>  
>
>> If in the iscsid.conf you see this for 
>> node.session.timeo.replacement_timeout then this is what I think you are 
>> asking for (that is if you are saying you do not want IO failed) and you 
>> want to set the value to 0.
>> # - If the value is 0, IO will be failed immediately.
>> # - If the value is less than 0, IO will remain queued until the session
>> # is logged back in, or until the user runs the logout command.
>>
>> > - Try every 1 second
>> > - Timeout should work for all stages of the session,
>> > be it logged in or not.
>>
> Even though I changed node.session.timeo.replacement_timeout to 300, It is 
> not updating the value in file 
> /sys/class/iscsi_session/session<id>/recov_tmo  because of multipathd 
> service is taking upper hand of iscsi_timeout setting and making it to 5 
> seconds. Is there anyway to change the value without stopping multipathd 
> service?? 
>
>>
>>
There is always a trade-off when using timeouts with multipathng. You want 
the failure to be detected fairly quickly with multi-pathing so that you 
can fail over to the other path. If you have a long failure timeout, then 
the timeouts for multi-pathing become *really* long, because they use the 
individual path timeouts times the number of paths. So if you have a 
300-second failure timeout and two paths you could easily have a 600-second 
timeout for the MP device. This is likely why the MP software sets the 
timeout to 5 seconds. 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to