Comment 15 for bug 381300

@Andrea, your report is closely related to some other reports including #343371 and #131094. See my comment and request at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094/comments/235. In your case, there are (potentially) two issues. First, there is the latency under I/O load and, second, there may be still an issue with cfq with the pen drive. We would like you to do the testing described in the comment link first and if there is still a pen drive problem, we can address that next.

The I/O schedulers have been focused primarily on HDDs. The typical drive has a shared filesystem on it and, being mechanical, has rotational and seek latencies that must be compensated for. The CFQ scheduler does a pretty good job of fair and sustained throughput in that environment. On the other hand, SSDs and pen drives, actually any flash based device, have a different set of constraints. There is no seek/rotational latency at all but write performance can be pretty bad, especially for small, random writes. This is because the controller in the drive must read a whole block (usually 64k+), copy the small write into it, erase the block, and then, finally, write the block back, most often in a different location to "wear level" the device. SSDs are still evolving but current parts do not perform well with short writes. They are getting better but they are not there yet. This is a work in progress. Pen drives do not get even this much attention given that they are a single user/task, offline storage device.

Using NOOP scheduling does seem to work better than CFQ for these devices but from your comment, the dd is only doing 512 byte "records". Try using a larger block size (> 1MB). That seems to work well enough to make scheduling a non-issue.

I have changed this to incomplete pending your test results. I may mark it as a duplicate based on those results.

Thanks