Michael Reed wrote:
Stefan Richter wrote:
[...]
I think the 2nd parameter does not help anyone. What you rather seem to
need is
a) the existing dev_loss_tmo parameter but without the kernel
enforcing an upper limit for it [the admin sets the policy, not
the kernel], and
b) the transport layer or the SCSI core taking care that no SCSI
command times out during the tolerated absence of a target.
Actually, I do not want this. The limit on the dev_loss_tmo parameter
is there to allow error notification to eventually pass up the stack.
This is important in path failover situations. An infinite value here
would imply that commands do not time out.
Wouldn't be path failover simply mean that the transport returns the
target from "absent" to "available" when the alternative path kicks in?
This should happen much earlier than after 'infinite' time.
[...]
The transport currently holds off commands with a combination of DID_IMM_RETRY,
blocking the target so that no new commands are issued, and holding off
error recovery until the dev loss timer expires.
Ah, I didn't know that yet. Still, people should think about moving this
or similar behaviour (IOW, the notion of "temporarily absent" state of
targets or units) up into SCSI core. Then the remaining responsibility
of the transport is to determine _when_ to report which connection state
transitions (based on hardware events, user-configurable timers, sysfs
events etc.), not _how_ to handle tasks for these targets or units in
the various states.
This is the behavior that is desired.
What I want is to have the device, when it returns, reconnect to it's
existing infrastructure. This allows previously connected "users"
to reconnect.
Yes, clearly.
--
Stefan Richter
-=====-=-==- -==- -===-
http://arcgraph.de/sr/
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
