The end of block barriers [LWN.net]

The end of block barriers

Posted Aug 19, 2010 11:31 UTC (Thu) by zmi (guest, #4829)
In reply to: The end of block barriers by butlerm
Parent article: The end of block barriers

You partly answered a question I had to the article: What makes the new algorithm that much faster than barriers? When I still send a "cache must be flushed" request to the device, even normal writes are stopped until the device flush it's cache, and it will take some time to fill the cache again to get good performance, during that another flush might incur...

Think of a simple file server, where 3 persons copy files to:
Person 1 copies his MP3 collection to the server.
Person 2 copies her HD-video collection to the server.
Person 3 runs a highly parallel intensive write database.

While for 1 and especially 2 there will be very low metadata operations, 3 generates lots of fsync's. From the article I read that a full cache flush would happen, suspending even the normal writes of person 1+2. Or am I misinterpreting that?

(Log in to post comments)

The end of block barriers

Posted Aug 19, 2010 13:13 UTC (Thu) by corbet (editor, #1) [Link]

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.

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.