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

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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/