> > In article <20010713231551.A4192@antioche.eu.org> Manuel Bouyer wrote:
> > > Hi,
> > > I'd like to add 2 functions to the scispi code:
> > > - scsipi_target_detach()
> > [...]
> >
> > Could you please also add some functionality to scsictl to detach
> > devices?  E.g. for scanners, which you only turn on for as long as you
> > need them, so that they can be properly detached when you turn them
> > off.
> >
> > Or is that the wrong function for that?
>
> I don't know. Maybe devices should just be detached when the adapter returns
> SELTIMEOUT

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.).

>... 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.".

-matt