I have this problem too. HP Pavilion (Core 2 Quad, 3 GB RAM, 2.6.31-17-generic x86_64)
I was unable to use dd to write a memstick image to a Sandisk USB stick. It was crawling to a virtual stop before reaching 40% complete. I hope my observations will help to solve this problem.
My first observation was that I could use dstat output to anticipate the slow down and then press "Ctrl-Z" to suspend the dd so that the write buffers could drain. Carefully nursing the transfer along resulted in a successful and quick copy.
My other observation was that I could work around this problem using the "oflag=direct" option to dd, which presumably bypasses the lazy write buffering.
# dd if=sandisku3.dd of=/dev/sdh bs=256k oflag=direct
7839+1 records in
7839+1 records out
2055021056 bytes (2.1 GB) copied, 217.913 s, 9.4 MB/s
I think these observations suggest that the extremely high write backlog (over 700MB "Dirty" in /proc/meminfo) causes a performance fall-over when available memory resources become exhausted.
I have this problem too. HP Pavilion (Core 2 Quad, 3 GB RAM, 2.6.31-17-generic x86_64)
I was unable to use dd to write a memstick image to a Sandisk USB stick. It was crawling to a virtual stop before reaching 40% complete. I hope my observations will help to solve this problem.
My first observation was that I could use dstat output to anticipate the slow down and then press "Ctrl-Z" to suspend the dd so that the write buffers could drain. Carefully nursing the transfer along resulted in a successful and quick copy.
My other observation was that I could work around this problem using the "oflag=direct" option to dd, which presumably bypasses the lazy write buffering.
# dd if=sandisku3.dd of=/dev/sdh bs=256k oflag=direct
7839+1 records in
7839+1 records out
2055021056 bytes (2.1 GB) copied, 217.913 s, 9.4 MB/s
I think these observations suggest that the extremely high write backlog (over 700MB "Dirty" in /proc/meminfo) causes a performance fall-over when available memory resources become exhausted.