Re: [PATCH] make fc transport removal of target configurable

Stefan Richter
2006-06-13T23:16:37Z

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
-=====-=-==- -==- -===-