Approximately twice a week, the entire graphical interface will lock up for about 10-20 seconds without warning while I am doing simple tasks such as browsing the web or writing a paper. When this happens, GUI elements do not respond to mouse or keyboard input, and the System Monitor applet displays 100% IOWait processor usage.
Today, I finally happened to have GNOME Terminal already open when the problem started. Despite other applications such as Google Chrome, Firefox, GNOME Do, and GNOME Panel being unresponsive, the terminal was usable. I ran iotop and observed that commands named [flush-8:16] and [jbd2/sdb2-8] were alternately using 99.99% IO.
What are these, and how can I prevent them from causing GUI unresponsiveness?
Details
$ mount | grep ^/dev
/dev/sda1 on / type ext4 (rw,noatime,discard,errors=remount-ro,commit=0)
/dev/sdb2 on /home type ext4 (rw,commit=0)
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sdb3 partition 1052252 0 -1
/dev/sda is an OCZ-VERTEX2 and /dev/sdb is a WD10EARS. Here is dumpe2fs /dev/sdb2 and smartctl /dev/sdb --all.
I don't see anything unusual in dmesg or /var/log/syslog.
flushwrites the RAM buffer/cache to disk, and jbd2 deals with the ext4 journal. – j-g-faustus Mar 13 '11 at 18:01/dev/sdaas well - which disk holds what? Like "root on sda, home on sdb"? – j-g-faustus Mar 13 '11 at 19:52dmesgfor disk errors. – arrange Mar 13 '11 at 22:43