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

[Eric D. Mudama]

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?

--eric



--
Eric D. Mudama
edmudama@xxxxxxxxxxxxxxxxxxxxx

-
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/