Messages in this thread | | | Date | Fri, 11 Jun 2004 18:50: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, Eric D. Mudama wrote: > On Fri, Jun 11 at 9:55, Jens Axboe wrote: > >Proposal looks fine, but please lets not forget that flush cache range > >is really a band-aid because we don't have a proper ordered write in the > >first place. Personally, I'd much rather see that implemented than flush > >cache range. It would be way more effective. > > So something like: > > WRITE FIRST PARTY DMA QUEUED BARRIER EXT > READ FIRST PARTY DMA QUEUED BARRIER EXT > READ DMA QUEUED BARRIER EXT > READ DMA QUEUED BARRIER > WRITE DMA QUEUED BARRIER > WRITE DMA QUEUED BARRIER EXT > > > ... > > 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. > > Multiple barrier operations can be in the queue at the same time. A > barrier operation has an implied FUA associated with it, such that the > command (and all previous-in-time commands) must be pushed to the > media before command completetion can be indicated. > > > Is that what would be most useful?
That is _spot on_ the best implementation for writes and what I have asked for all along :-). I have nothing to add to the above.
I don't have an immediate use for the read-barrier requests (btw, I think we should call it WRITE_DMA_QUEUED_ORDERED and so forth, clearer naming), though.
-- 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/
| |