[EMAIL PROTECTED] wrote:
fast_io_fail_tmo
iscsi: session recovery_tmo
fc: rport fast_io_fail_tmo
The difference is that when the timer fires, for iscsi we unblock the
queue and fail commands in the blocked queue. FC just fails IO running
in the driver/fw/hw. The IO in the blocked queue sits
So my position changes a little now that you pointed out that you
release the request queue when fastfail kicks in.
Mike Christie wrote:
Do we want to fail IO that was sitting in the queue _and_ all new
incoming IO or just what was sitting in the queue?
I believe all i/o - so that the upper
From: Mike Christie [EMAIL PROTECTED]
Small guide to differences in iscsi and fc:
I_T nexus or port we are connected to at some other end point
iscsi: iscsi_session
fc: rport
fast_io_fail_tmo
iscsi: session recovery_tmo
fc: rport fast_io_fail_tmo
The difference is that when the timer fires,
[EMAIL PROTECTED] wrote:
The following patches attempt unify what upper layers will see drivers
like multipath can make a good guess. This relies on drivers being
Oops, I mean to say with the patches upper layers like multipath will
see common behavior from LLDs hooked into transport classes.
[EMAIL PROTECTED] wrote:
When using multipath and the fast_io_fail_tmo fires then the class
can fail commands with DID_TRANSPORT_FAILFAST or drivers can use
Bah, that is going to be wrong or ugly for tape commands.
We would want to add another new value, DID_TRANSPORT_ABORTED which
would check
5 matches
Mail list logo
