On Sun, Jul 15, 2001 at 01:10:42PM -0700, Matthew Jacob wrote:
> No, no, no, no.... That's up to the target device driver to decide (sd, st,
> etc)... what to do about. It has to be the one to know whether or not a
> SELTIMEOUT is bad.
> 
> But even that should not be deterministic.
> 
> You'll get a bunch of SELTIMEOUTS when devices (momentarily) leave a fabric
> for Fibre Channel. It's impossible to tell a priori if they'll show back up
> again. They might. They might not. It'll take a while (2 to 30 to infinite
> seconds depending on how bad things get) to sort it out.
> 
> You *could* detach 'em all, but then you get these attach/detach floods that
> Solaris has (which are awful, and in anything other than trivial topologies
> there's almost invariably a disk that falls off the back of the truck when
> this happens), and the detaches will fail if the device itself is open.
> 
> It's perhaps best in this case to let the target device driver decide, based
> on policy, whether it wants to wait for a period before it begins to start
> failing commands and then up to the caller's cleverness as to what it would
> like to do (detach, retry, fallback to alternate volumes, etc.).

Hum, I think this should be in the core scsipi itself, not in upper
level drivers. It's better to have a consistent behavior for all devices.

Now, I agree that commands failing with SELTIMEOUT should not be failed
immediatly, but retried after a short period of time. If the device fails
to respond to selection after some time, detach it.

> >... but this would mean that turning off a drive would make
> > it detach. I don't know if it's desireable.
> 
> No, it's not.
> 
> But having a scsictl to detach a device *is* a good thing. This allows you to
> write tools that say "this device is gone- no matter what. It's gone because I
> say so.".

OK. We can add this one, it's easy.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--