Hide Forgot
- 2.6.24.7-108.el5rt # echo 3 > /proc/sys/vm/drop_caches # sync; time `dd if=/dev/zero of=ddfile2 oflag=sync bs=4k count=20000; sync` 20000+0 records in 20000+0 records out 81920000 bytes (82 MB) copied, 16.956 seconds, 4.8 MB/s real 0m17.273s user 0m0.022s sys 0m0.882s - 2.6.33.7-rt29.47.el5rt # echo 3 > /proc/sys/vm/drop_caches # sync; time `dd if=/dev/zero of=ddfile2 oflag=sync bs=4k count=20000; sync` 20000+0 records in 20000+0 records out 81920000 bytes (82 MB) copied, 315.311 seconds, 260 kB/s real 5m15.559s user 0m0.007s sys 0m1.037s This is using the cfq I/O scheduler. There is not a similar drop in performance when the deadline scheduler is used.
Talking with the fs folks, this is not a bug. It was a bug fix. Doing a sync write with dd is _suppose_ to be slow. The old kernel was not doing the proper sync with the hard drive, which is why it performed so well. But that good performance was a symptom of a bug, not a feature. Fixing the bug caused performance to take a hit, and the slow sync dd is correct. Perhaps we should look at why the deadline scheduler is performing so well. Perhaps it is not working either.