lkml.org 
[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:2.322 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site