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. > libata EH was coded to largely be "in the driver's seat", which isn't > true in a world where it is a peer to SAS devices. Also libata EH > duplicates some of the link EH stuff that SAS deals with, and must > subsume (since libsas knows about both SAS and SATA phys, and an ideal > world doesn't have the two as separate as they are now). Yes ... there's even nastier scenarios. If we're in a STP (SATA Tunnel Protocol) situation, the device at the end is SATA, but the pathway to get to it through the port is SAS via expanders. In that situation the two have to co-operate on the recovery ... of course, this isn't incredibly dissimilar from port multipliers now. James -- 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
