| |||||||||||||
The end of block barriersThe end of block barriersPosted Aug 19, 2010 13:13 UTC (Thu) by corbet (editor, #1)In reply to: The end of block barriers by zmi Parent article: The end of block barriers The cache flush can happen in parallel with other I/O. Forcing specific blocks to persistent media can only slow things down, but they have to get there soon in any case. While the drive is executing the cache flush, it can be satisfying other requests whenever it's convenient. "Cache flush" doesn't mean "write only blocks in the cache" or "don't satisfy outstanding reads while you're at it". It will be far more efficient than a full queue drain.
(Log in to post comments)
The end of block barriers Posted Aug 19, 2010 15:25 UTC (Thu) by butlerm (subscriber, #13312) [Link]
The problem is that in general an fsync requires a journal commit. If you have to flush the entire write cache throughput for non-fsync-serialized threads might be fine, but the performance of threads that call fsync will seriously suffer due to the delay.
Flushing the write cache of the device a lot also moves the request ordering / merging efficiency problem down a level. If the device must flush the entire write cache on a regular basis, it has much reduced opportunity to order write operations as optimal for that device.
|
|||||||||||||