Timeout settings not working?

[Ian Pilcher]

I am trying to set up a purely virtual dm-multipath demo environment
with Open-iSCSI and tgtd. tgtd is running on a Fedora 17 host, on which
I have also created two Open vSwitch bridges to serve as storage
networks. The guest is RHEL 6.3 (kernel-2.6.32-279.11.1.el6.x86_64 and
iscsi-initiator-utils-6.2.0.872-41.el6.x86_64).

I have been unable to get network errors recognized in a timely manner.
For example, if I run a command such as "dd if=/dev/zero of=/dev/sdb"
(where sdb is one of the paths to the iSCSI target), it takes around
130 seconds for an error to be reported (when I use an iptables rule on
the host to block traffic on the appropriate bridge).

Timeout-related entries from /etc/iscsi/iscsid.conf are:

node.session.timeo.replacement_timeout = 5
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.session.err_timeo.abort_timeout = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.tgt_reset_timeout = 30

The timeout values reported by "iscsiadm -m session -P 3" are:

Recovery Timeout: 120
Target Reset Timeout: 30
LUN Reset Timeout: 30
Abort Timeout: 15

(The recovery timeout jumps out at me. Shouldn't it match the
replacement_timeout from the configuration file?)

The value of /sys/block/sdb/device/timeout is 30.

Any pointers on what I should be changing (or additional information I
should gather) are appreciated.

Thanks!

--
========================================================================
Ian Pilcher arequ...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

[Mike Christie]

Not necessarily. The iscsid.conf values are the defaults values used to
setup portal/node records.

Run

iscsiadm -m node -T yourtarget -p ip

to see the per portal value being used. The iscsid.conf values are used
when we create new portal/node records. If you want to update a setting
on a existing record either rediscover the target (this will overwrite
all the existing records) or run

iscsiadm -m node -T yourtarget -p ip -o update -n name.of.setting -v
newvalue

then relogin to the target.

Besides the recovery/replacement timeout you would want a lower noop
timeout. So set

node.conn[0].timeo.noop_out_interval
and
node.conn[0].timeo.noop_out_timeout

lower.


It also depends on your dm-multipath setup, and how you are testing. Are
you removing all paths? What is the queue_if_path or no_path_retry values.

Checkout "8. Advanced Configuration" of the readme in
/usr/share/docs/iscsi-intiator-utils-$VERSION/REAMDE

[Ian Pilcher]

On 11/02/2012 03:36 PM, Mike Christie wrote:
> Run
>
> iscsiadm -m node -T yourtarget -p ip
>
> to see the per portal value being used. The iscsid.conf values are used
> when we create new portal/node records. If you want to update a setting
> on a existing record either rediscover the target (this will overwrite
> all the existing records) or run
>
> iscsiadm -m node -T yourtarget -p ip -o update -n name.of.setting -v
> newvalue
>
> then relogin to the target.

Aha! That explains that.

After making that change, the "recoverable transport error" is now
reported within 13 seconds.

>
> Besides the recovery/replacement timeout you would want a lower noop
> timeout. So set
>
> node.conn[0].timeo.noop_out_interval
> and
> node.conn[0].timeo.noop_out_timeout
>
> lower.

RHEL 6.3 already has those set to 5, so I didn't have to change them.

> It also depends on your dm-multipath setup, and how you are testing. Are
> you removing all paths? What is the queue_if_path or no_path_retry values.

I'm currently testing by writing to a single path.

no_path_retry is set to fail. queue_if_no_path (I assume that's what
you meant) is not explicitly set.

> Checkout "8. Advanced Configuration" of the readme in
> /usr/share/docs/iscsi-intiator-utils-$VERSION/REAMDE

Believe me, I read that before posting.

Ultimately, I just didn't realize that changes to the settings in
iscsid.conf would not affect already discovered targets. Now that I
know that, I believe I'm good. (At least my next question will probably
to to the dm-multipath list.)

[Michael Christie]

On Nov 2, 2012, at 4:35 PM, Ian Pilcher <arequ...@gmail.com> wrote:
>
>> Checkout "8. Advanced Configuration" of the readme in
>> /usr/share/docs/iscsi-intiator-utils-$VERSION/REAMDE
>
> Believe me, I read that before posting.
>
> Ultimately, I just didn't realize that changes to the settings in
> iscsid.conf would not affect already discovered targets.

Ok. I think that is a common mistake, because the tools are odd in that way. I will add some more notes in the README about that. Thanks.

[Periyannan, Jaikumar]

Michael Christie <mich...@cs.wisc.edu> wrote:

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
@To post to this group, send email to open-...@googlegroups.com.
To unsubscribe from this group, send email to open-iscsi+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.