Christoph Hellwig, on 07/30/2010 12:03 AM wrote:
On Thu, Jul 29, 2010 at 02:59:51PM -0500, James Bottomley wrote:
That's basically everything FUA ... you might just as well switch your
cache to write through and have done.
This, by the way, is one area I'm hoping to have researched on SCSI
(where most devices do obey the caching directives). Actually see if
write through without flush barriers is faster than writeback with flush
barriers. I really suspect it is.
We have done the research and at least for XFS a write through cache
actually is faster for many workloads. Ric always has workloads where
the cache is faster, though - mostly doing lots of small file write
kind of setups.
I supposed, with write back cache you did the queue drain after
request(s) with ordered requirements, correct? Did you also do the queue
drain in the same places with write through caching?
Just in case, to be sure the comparison was fair. I can't see why
sequence of [(write command/internal cache sync) .. (write
command/internal cache sync)] for write through caching should be faster
than sequence of [(write command) .. (write command) (cache sync) ..
(write command) .. (write command) (cache sync)], except if there are
additional queue flushing (draining) in the latter case. I think we need
to explain that before doing the next step.
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
