Comment 6 for bug 635181

(sigh) another drive by comment for karma points.

In the NFS situation I would expect NFS tasks to 'float high' in regular TOP. No such items are seen at the top of top. The 'meta' information in iotop does not seem to be totally broken. The Total Disk Read and Disk Write stats though may be not as accurate in their totals they still reflect activity under normal operation. The "zero" I speak of above is that line showing zero to a few byes of activity with rsync sending the LA1 to 6 or more.

The issue manifests itself in NFS copying via rsync, dd from /dev/zero to a usb device, and on SATA to SATA moves of large VDI files. If a simple dd=/dev/zero of=/path/to/usb/file bs=1024 count=1M sends the load average sky high (on two different guests on two different parents and one parent is running 10.04) something is wrong on 10.04. It did not operate this way before. I should not need to render my parent or guests useless moving 30 GB vdi images from one disk spindle to another. Nor should I need to "put up with" (as seen in the sar output attached to the case) load averages for idle systems that, for no apparent reason, migrate above 1.00 or more. If you had read my other posts on 574910 you would have noted that regressing the kernel to a 9.10 version improves the issue, but does not totally resolve it.

There are more instance types. See my posts in 574910.

NB: As to the "broken" state of iotop, Only CONFIG_TASK_DELAY_ACCT seems to be disabled in Lucid. CONFIG_TASK_DELAY_ACCT used for intra-task prioritization[1] and seems only to disable the SwapIn and IO %. So, unless I have missed other posts where it states that iotop is totally broken, the package is still valid for meta information. (BTW if CONFIG_TASK_DELAY_ACCT is disabled due to "performance" issues, why not disable SMP on all kernels too since that is a performance hit too for all non SMP hosts).

1 https://lists.ubuntu.com/archives/kernel-team/2009-December/008029.html