recommend setting for dev_loss_tmo and fast_io_fail_tmo

recommend setting for dev_loss_tmo and fast_io_fail_tmo

[Vasiliy Tolstov]

Hello. I'm using 3.9.5 and ib_srp_backport from github.
What is recommended setting for dev_loss_tmo and fast_io_fail_tmo ?
Now i have
dev_loss_tmo = 60
fast_io_fail_tmo = 40

Does it right?

I need to wait no more 100 seconds for failed path. (i'm use some xen
vm on this host and it linux kernels not like to stuck more than 120
seconds =))

--
Vasiliy Tolstov,
e-mail: v.tolstov-+9FY0jupvH6HXe+LvDLADg@public.gmane.org
jabber: vase-+9FY0jupvH6HXe+LvDLADg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recommend setting for dev_loss_tmo and fast_io_fail_tmo

[Bart Van Assche]

On 06/13/13 17:52, Vasiliy Tolstov wrote:
> Hello. I'm using 3.9.5 and ib_srp_backport from github.
> What is recommended setting for dev_loss_tmo and fast_io_fail_tmo ?
> Now i have
> dev_loss_tmo = 60
> fast_io_fail_tmo = 40
>
> Does it right?
>
> I need to wait no more 100 seconds for failed path. (i'm use some xen
> vm on this host and it linux kernels not like to stuck more than 120
> seconds =))

Hello Vasily,

The default value for the reconnect_delay parameter in that version of 
the SRP initiator is 10 seconds. So if you want to give the SRP 
initiator a chance to try once to reconnect before failing I/O fast you 
can set the fast_io_fail_tmo parameter to e.g. 15 seconds. That should 
limit the time during which I/O is stuck to about 76 seconds (61 seconds 
IB RC timeout + 15 seconds for the fast I/O fail timeout). How to 
configure dev_loss_tmo depends on the configuration at the initiator 
side. If you are using initiator-side mirroring then it is a good idea 
to set dev_loss_tmo to a very large value in order to avoid /dev/sd* 
reassignment. Note: with the patch series I posted earlier this week it 
is possible to set dev_loss_tmo to "off", something that is not yet 
possible with the ib_srp-backport project.

Bart.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recommend setting for dev_loss_tmo and fast_io_fail_tmo

[Vasiliy Tolstov]

2013/6/13 Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>:
> Hello Vasily,
>

Hello, Bart.

> The default value for the reconnect_delay parameter in that version of the
> SRP initiator is 10 seconds. So if you want to give the SRP initiator a
> chance to try once to reconnect before failing I/O fast you can set the
> fast_io_fail_tmo parameter to e.g. 15 seconds. That should limit the time
> during which I/O is stuck to about 76 seconds (61 seconds IB RC timeout + 15
> seconds for the fast I/O fail timeout).

Hm. Does it mean that if i set fast_io_fail_tmo = 40 i get timeout
after 61+40 = 101 seconds?

>How to configure dev_loss_tmo
> depends on the configuration at the initiator side. If you are using
> initiator-side mirroring then it is a good idea to set dev_loss_tmo to a
> very large value in order to avoid /dev/sd* reassignment. Note: with the
> patch series I posted earlier this week it is possible to set dev_loss_tmo
> to "off", something that is not yet possible with the ib_srp-backport
> project.

Yes, i'm using raid1 on initiator side. That means that in my case
dev_loss_tmo may be switched off?

P.S. In case of kernel 3.9.5 does i need you backported ib_srp driver
or i can use mainline kernel drivers for faster reconntects?
P.P.S. Can you provide me subject of e-mail or link to patches to
switch off dev_loss_tmo?




--
Vasiliy Tolstov,
e-mail: v.tolstov-+9FY0jupvH6HXe+LvDLADg@public.gmane.org
jabber: vase-+9FY0jupvH6HXe+LvDLADg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recommend setting for dev_loss_tmo and fast_io_fail_tmo

[Bart Van Assche]

On 06/13/13 20:21, Vasiliy Tolstov wrote:
> P.S. In case of kernel 3.9.5 does i need you backported ib_srp driver
> or i can use mainline kernel drivers for faster reconnects?
> P.P.S. Can you provide me subject of e-mail or link to patches to
> switch off dev_loss_tmo?

Hello Vasiliy,

Does this mean that you are not subscribed to the linux-rdma mailing 
list ? A patch series that allows faster reconnects and that allows to 
disable dev_loss_tmo is currently under review. See e.g. 
http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg15628.html.

Bart.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recommend setting for dev_loss_tmo and fast_io_fail_tmo

[Vasiliy Tolstov]

2013/6/14 Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>:
> Hello Vasiliy,
>
> Does this mean that you are not subscribed to the linux-rdma mailing list ?
> A patch series that allows faster reconnects and that allows to disable
> dev_loss_tmo is currently under review. See e.g.
> http://www.mail-archive.com/linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg15628.html.


I'm subscribed, but i have high volume e-mails from lkml,scst,libvirt,
etc and may missed some emails when reading..
Thanks for link!


--
Vasiliy Tolstov,
e-mail: v.tolstov-+9FY0jupvH6HXe+LvDLADg@public.gmane.org
jabber: vase-+9FY0jupvH6HXe+LvDLADg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html