On Thu, Apr 15, 2004 at 07:12:43PM -0700, Jason Thorpe wrote:
> 
> On Apr 15, 2004, at 2:05 PM, Manuel Bouyer wrote:
> 
> >>You'd also have to teach our HBA drivers to not rudely abort other 
> >>HBA's
> >>queued requests on the whole bus with a SCSI bus reset.
> >
> >The others HBA drivers should be able to handle this
> 
> I think you missed his point.
> 
> Consider the following topology:
> 
>      Server A -----+----- Server B
>                    |
>                    |
>            Shared Disk Pool
> 
> Server A and Server B are coordinating access to Shared Disk Pool, both 
> have outstanding commands with the Shared Disk Pool.
> 
> Now, Server A reboots (due to a crash or whatever).  NOTE: Server B is 
> still using Shared Disk Pool and has outstanding commands!

Yes

> 
> Right now, when Server A comes back up, it issues a SCSI Bus Reset, 
> which KILLS any commands that Server B has running on the Shared Disk 
> Pool.  All of those commands error out, and you see a major drop in 
> performance as Server B has to recover.

No, it's not a major drop in performances. It's of the same order as a
queue full condition (a little bit more, but not much more).

> 
> This is not a good thing.  And there is no good reason for Server A to 
> issue that SCSI Bus Reset in the first place.

There is: to start from a known state.
And anyway, firmware also issue scsi bus reset. Some target also issue a bus
reset at power up.

scsi bus reset exists, it's a fact. We have to live with it.
And I don't think adding extra complexity to the probe system to avoid a
bus reset at boot is worth it.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--