Messages in this thread | | | Date | Fri, 27 May 2005 09:15:52 +0200 | From | Jens Axboe <> | Subject | Re: Playing with SATA NCQ |
| |
On Fri, May 27 2005, Jeff Garzik wrote: > Jens Axboe wrote: > >Yeah, I'm not a huge fan of the need for the above code... If every qc > >was tied to a SCSI command, we could just ask for a later requeue of the > >request as is currently done with NCQ commands. Alternatively, we could > >add an internal libata qc queue for postponing these commands. That > >would take a little effort, as the sync errors reported by > >ata_qc_issue() would then be need to signalled async through the > >completion callback instead. > > > >Jeff, what do you think? > > Just use the SCSI layer for requeueing. That's what I intended.
Yep, that is what I'm doing for SCSI originated commands.
> Every qc that matters can be requeued. Just don't worry about > non-queued, non-fast-path commands. They are typically used in > functions that will immediately notice a failure, and handle it > accordingly.
So the current wait-around stuff is ok with you?
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |