John Reddy wrote:
> Obviously looking for some help, if any is there to be had.
> Behavior I'm seeing is a log entry stating "ping timeout of 5 secs
> expired" then session dropped.  Roughly 2 seconds of "Failing
> command..." then the session is re-established.  (log excerpt below).
> This has been caused corruption in the ext3 journal, making the
> filesystem go read-only until its fsck'd.
> I'm seeing a few ways this could be debugged, but I'm still new to
> iSCSI, so direction would be appreciated.  The "ping timeout of 5 sec"
> followed by 2 seconds, followed by re-establishing.  Is there a
> tunable parameter that I missed which would make the system less
> vulnerable these inexplicable lags?

In /etc/iscsi.conf there is:


If you set these to zero it would turn that off. You can also set it 
higher to a 30 secs or whatver is safest for your setup.

You also might want to consider using dm-multipath over iscsi, and then 
using dm-multipath's no_path_retry option.

> I still yet to investigate the source of these lags.  The system does
> push a lot of traffic, ~ 200Mbit/sec sustained over the Gig eth.  I've
> also looked at updating my ethernet drivers.  The Broadcom drivers
> have been updated since the version released with SL 4.6

The initiator will send the target a iscsi ping every ActiveTimeout 
seconds if IO is running (if no IO is running it will send it every 
IdleTimeout).  If the initiator does not get a response to the nop 
within PingTimeout seconds you get the Ping timeout failover. If then 
that happens 5 times to the same command it is failed to the FS and you 
get the FS errors.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to