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

[Mike Christie <michaelc@cs.wisc.edu>]

James Bottomley wrote:
> On Tue, 2006-06-13 at 14:37 -0500, Michael Reed wrote:
>> Not really true as the transport holds off the error handler until the
>> transport dev loss timer expires.
>>
>> And afterwards, commands are returned immediately with DID_NO_CONNECT.
>> The device is never offlined (with my patch applied).
> 
> That was just a general examination of the options for retaining contact
> with the target.
> 
> It seems we both agree that returning an error is about the only viable
> option, in which case the user or application has to take a recovery
> action anyway, so there's no logical difference between what you propose
> and what we currently do as far as the application or filesystem is
> concerned.
> 
> The only difference is what happens if the device reappears.  However,
> since the application has to be modified in either case:  your patch to
> continually probe with I/O to see if the device has returned, or the
> existing case to wait out the udev event that says the device is back it
> doesn't really buy us anything for the application.  Since the rest of
> our infrastructure is already event driven, or migrating that way, I
> really don't see value in introducing an anomaly like this purely for
> fibre channel.
> 

For iscsi we do sort of the probe option. The problem with software
iscsi is that we do not normally get a event that some target is back
online so from userspace we basically have to probe it. We try to open a
connection and poll it until it we can connect, then we try to log back
in. When we log back in, we set the devices online if we have to and we
set the driver and iscsi state to start accepting IO again.

For HW iscsi the card can signal an event that it has logged back into a
target, so we could do like FC. So for qla4xxx, should we follow the FC
model or software iscsi one that is already there?

Note, that for software iscsi we could do FC's model too. When
dev_loss_tmo expires we could remove the session/target. Then we could
just create the connection, poll, and if we successfully login we could
then create the session/target structs again.