On 13-11-18 10:54 AM, Phillip Susi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/17/2013 8:06 PM, Phillip Susi wrote: >> I don't see anything particularly inefficient about issuing the >> command in the eh path ( in fact, libata always uses the eh path to >> handle power management ). You can of course, use the >> manage_start_stop flag to have the disk start on resume if you >> really want. > > Yikes, I think I see now why scsi eh is so bad: the entire host, not > just the device is quiesced. > > I suppose now the question is how to issue the START STOP UNIT from > sd_prep_fn()? I gather you can't just call scsi_execute_req() from > there? Is there maybe a way to insert a START STOP UNIT request into > the queue ahead of the current request being prepped? Can > sd_prep_fn() be called concurrently on multiple cpus? Hrm.. what > about TCQ? Would it be bad if the original request were queued ( to > the drive ) before the START STOP UNIT command completed? Yeah, solve that, and you're golden. I totally understand the motivation for this patch, and would love to have it working on my machines here too. But it may have to be some kind of sysfs optional setting, defaulting to current behaviour, to keep the server keepers happy. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
