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
.
flush
writes the RAM buffer/cache to disk, and jbd2 deals with the ext4 journal./dev/sda
as well - which disk holds what? Like "root on sda, home on sdb"?dmesg
for disk errors.