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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
