Re: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later)

[Jens Axboe]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/