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

[Jeff Garzik]

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

Honestly, Linux at least isn't going to care about "legacy TCQ" at all, 
unless in the very rare case that the controller implements TCQ support 
in hardware.

The overall difficulty with implementing atomic updates, journalling, 
barriers etc. on ATA is that traditionally the OS had no clue what was 
in the write cache, and what was actually on the platter.

Thus, I think that an FPDMA queued FUA read/write should be all that's 
needed, since that automatically gives the OS the knowledge of ordering, 
which gives barriers what they need.  Ordering need only be a matter of 
waiting for the hardware queue (all FUA commands) to drain, and then 
issuing an FUA commit block.

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


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

	Jeff


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