Eric D. Mudama wrote:
On 5/16/06, Jeff Garzik <jeff@xxxxxxxxxx> wrote:Ric Wheeler wrote: > But when I test with my synchronous write load, I am going at 6 times > the normal rate (i.e., the rate I see with barriers disabled) ;-) Well, NCQ read/write commands have a 'FUA' bit... though maybe the NCQ code forgot to check the global libata_fua. JeffIs the workload a sequential write? SATA drives should be able to keep up with the media if they use FUA for their consistency when using NCQ. Flush cache as a barrier mechanism will blow revs in sequential workloads, especially using a write/flush write/flush technique.
That would be a huge win for us, but this instance I mounted with barrier=flush (and that is the logged message in messages). I suspect that our boot with write cache disabled + flip of the write cache to on during boot is the culprit...
Once we get past the basic working/not working barriers, I will retest the FUA vs flush barriers and post some results ;-)
ric - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
