James Bottomley wrote: > On Mon, 2008-06-02 at 14:54 -0400, Jeff Garzik wrote: >> Brian King wrote: >>> One thing that having a per-port SCSI host buys us is that it isolates >>> EH to the port rather than the entire SCSI host. The way that the new >>> libata EH is designed, it can end up spending a fair amount of time >>> in EH and may even sleep for seconds at a time, waiting for the device >>> to come ready. Quiescing all devices on a SAS host due to a single >>> SATA device gets *very* painful. The new libata EH does much more than >>> just EH. It wakes up for every ATAPI check condition... >>> >>> Before we can move to a single SCSI host model, we will >>> have to make some changes regarding how EH is done in libata... >> >> Good points. There definitely needs to be a discussion about how to >> integrate libata EH with libsas model and ipr model (which are distinct, >> if similar). > > Actually, libsas completely hijacks the strategy handler (as I believe > libata does), so it really no longer has a host dependency, except for > the one thread per host thing. Most of what it does (unless it thinks > the actual host chip is wedged) is port (as in SAS port, not phy) based, > so I think we have the capability for doing this already. libsas currently does hijack the strategy handler today, but if we want to move it to the new libata EH/attach model, that's not going to work. libata EH does much more than EH. Its really more of an exception handler than an error handler. Anything that happens out of the ordinary wakes the EH thread. Ideally, I think we really want to have stacked EH as I believe we have discussed in the past. If we hit an error, we quiesce the device, do device level EH. If needed, quiesce the device group / port, perform EH. If necessary, quiesce the entire HBA and perform EH on it. -Brian -- Brian King Linux on Power Virtualization IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
