[6890] in linux-scsi channel archive
Re: Problem using "scsi add-single-device" >/proc/scsi/scsi
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sat Jul 24 09:58:19 1999
Date: Sat, 24 Jul 1999 16:10:03 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: Robin Miller uhs <rmiller@zk3.dec.com>
cc: lancer@airways.com, linux-scsi@vger.rutgers.edu
In-Reply-To: <199907241334.JAA0000689114@anw.zk3.dec.com>
On Sat, 24 Jul 1999, Robin Miller uhs wrote:
> Hi Folks,
> Having been down this road of hot-swap issues, I have a couple
> comments here as well...
>
> First off, while you may not wish to "formally" support hot-swap,
> the conditions which arise from unplugging a drive and/or powering a drive
> off, assuming proper termination is maintained, should be handled properly.
> That is, the SCSI bus should not be hung, and all outstanding I/O requests
> must be completed or rebooting the system is the only recovery action.
Indeed. Supporting Clause 10.3 of SPI-2 should be just fine even with
LVD buses.
> I'd also like to mention that noticing a "Selection Timeout" is
> useful for certain applications. For example, DEC's RAID controllers
> have a transparent controller failover feature using two controllers,
> so when one controller fails all I/O is automatically failed over to
> the other controller. During this failover process, "Selection Timeouts"
> occur, and upper drivers use this to retry until the failover completes,
> usually with 10-12 seconds.
Indeed. An heuristic based on selection timeouts is just fine to detect
controller and/or device failures.
> I'm used to a mature SCSI sub-system, implemented using CAM
> (Common Access Method). As Linux matures, I think CAM-3's advanced
> architecture may be worth considering. Please no flames!
Agreed. Modulo some minor clean-ups, CAM3 is probably the way to go.
Thanks for your posting.
> My 2 cents,
Change is about 10 centimes in France. :)
> Robin
[ End of flames. :-)) ]
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
