Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two 3TB disks in a software RAID 1 setup and the host OS is 64bit Debian wheezy.


dd if=/dev/zero of=test bs=64k count=3k oflag=direct && rm test


201326592 bytes (201 MB) copied, 1.423 s, 141 MB/s

If I alter the dd command to use synchronized IO calls (by changing the oflag switch from "direct" to "sync"), write peformance drops through the floor:

201326592 bytes (201 MB) copied, 76.0286 s, 2.6 MB/s

Obviously, synced IO results in a performance hit but I was expecting write throughput to drop to maybe half or a third (worst case) of the direct equivalent. 2.6MB/s seems extreme and makes me think there's a problem somewhere.

share|improve this question
up vote 1 down vote accepted

Synchronised IO stops until the block is written to disk and confirmed by the controller, so you end up waiting for at least one seek time between blocks. You're getting about 40 64k blocks per second, or one every 25 miliseconds. That's consistent with spending one 10ms seek time writing the data and another one updating the metadata in the inode, plus a bit of OS overhead.

This is why you don't want to use synchronised IO unless you really need strong consistency.

share|improve this answer
"<del>This is why you don't want to use synchronised IO...</del>" This is why you want to use hardware RAID with a BBU – JamesRyan May 9 '13 at 11:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.