From: Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org>
To: Vasiliy Tolstov <v.tolstov-+9FY0jupvH6HXe+LvDLADg@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: recommend setting for dev_loss_tmo and fast_io_fail_tmo
Date: Thu, 13 Jun 2013 19:56:42 +0200 [thread overview]
Message-ID: <51BA07DA.40703@acm.org> (raw)
In-Reply-To: <CACaajQuhmd8ExRHvQQBES43FNDWKGHxEb0DjmxWJ1K2=ybUuKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
next prev parent reply other threads:[~2013-06-13 17:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 15:52 recommend setting for dev_loss_tmo and fast_io_fail_tmo Vasiliy Tolstov
[not found] ` <CACaajQuhmd8ExRHvQQBES43FNDWKGHxEb0DjmxWJ1K2=ybUuKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-13 17:56 ` Bart Van Assche [this message]
[not found] ` <51BA07DA.40703-HInyCGIudOg@public.gmane.org>
2013-06-13 18:21 ` Vasiliy Tolstov
[not found] ` <CACaajQvBL_DvBXTaMOisuXUBzezpiQN6fSaio-VCOYYWpiaBHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-14 13:33 ` Bart Van Assche
[not found] ` <51BB1B9B.7080206-HInyCGIudOg@public.gmane.org>
2013-06-15 15:49 ` Vasiliy Tolstov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51BA07DA.40703@acm.org \
--to=bvanassche-hinycgiudog@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=v.tolstov-+9FY0jupvH6HXe+LvDLADg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.