Thanks Mike.
I have few follow-up question please. Why is this default replacement
timeout so high.
If I understand correctly in a multipath environment it is perfectly
alright to set it to 0 without
any side effect.
The other question is, how early iSCSI can detect session error , be it
with transport or target.
What if I set nop-out values as low as 1sec? In that case my paths shall be
failed over in 2sec?
Any optimized value for a virtual environment, where machines booted from
iSCSI luns and our
requirement is to achieve failover like fiber channel does, almost
immediately? Without instant
failover virtual machines just hangs as long as the path comes back or
failover to alternate path.
Kind regards,
Bubuli
On Wed, Jun 12, 2013 at 2:24 AM, Mike Christie wrote:
> On 06/07/2013 12:55 AM, Bubuli Nayak wrote:
> > Hello experts,
> >
> > I have learnt from MIke and others comment that multipath failover would
> > be driven by nop timout + nop interval + replacement_timeout seconds.
> >
> > My question is what is the impact I set replacement_timeout to 0. I know
> > if NOPOUT interval is low , more frequently iSCSI initiator would send
> > the commands.
> >
>
> It depends on the iscsi tools and kernel version you have. If in
> iscsid.conf you see the chunk about if the value is 0 it will be failed
> immediately and you have a recent kernel like 3.0 or newer or distro
> like RHEL 6 or SLES 11 then if you set it to 0 then it there will be no
> delay and IO will be failed as soon as we detect a error.
>
> # To specify the length of time to wait for session re-establishment
> # before failing SCSI commands back to the application when running
> # the Linux SCSI Layer error handler, edit the line.
> # The value is in seconds and the default is 120 seconds.
> # Special values:
> # - 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.
>
>
>
>
>
>
> > Appreciate any help you can offer. What value you would suggest if I
> > what multipath to take over as soon as iSCSI target fails.
> >
> > Kind regards,
> > Bubuli
> >
> > --
> > 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 http://groups.google.com/group/open-iscsi?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
--
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 http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
