Messages in this thread | | | Date | Fri, 11 Jun 2004 18:54:39 +0200 | From | Jens Axboe <> | Subject | Re: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later) |
| |
On Fri, Jun 11 2004, Jeff Garzik wrote: > Unfortunately, that's not the answer drive guys want to hear, because > FUA limits the optimization potential from previous ATA. ;-) Maybe > drive performance is high enough these days that queued-FUA as a > standard mode of operation is tolerable...
Data integrity doesn't come for free. Take a pick :-)
> >If the drive receives a queued barrier write (NCQ or Legacy), it will > >finish processing all previously-received queued commands and post > >good status for them, then it will process the barrier operation, post > >status for that barrier operation, then it will continue processing > >queued commands in the order received. > > If queued-FUA is out of the question, this seems quite reasonable. It > appears to achieve the commit-block semantics described for barrier > operation, AFAICS.
Actually from Linux's point of view, drive may reorder previously committed requests - just not around the barrier.
-- 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/
| |