Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


$ 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.

share|improve this question

closed as too localized by ændrük, Marco Ceppi Jun 2 '11 at 15:48

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

I can tell you what they are: They are part of the file system - flush writes the RAM buffer/cache to disk, and jbd2 deals with the ext4 journal. – j-g-faustus Mar 13 '11 at 18:01
Is this a laptop, by the way? – j-g-faustus Mar 13 '11 at 18:09
Just thinking aloud here: 100% IOWait could mean that the file system is waiting for the disk to wake from a low power state - agressive power saving is a major feature of the WD Greens. But not sure why it would lock the system. There's presumably a /dev/sda as well - which disk holds what? Like "root on sda, home on sdb"? – j-g-faustus Mar 13 '11 at 19:52
Could be a bad disk, check SMART data or output of dmesg for disk errors. – arrange Mar 13 '11 at 22:43
"too localized" -- too bad that I'm a future visitor who found this question because I'm looking at exactly the same problem. – DXM May 30 '13 at 21:55

I'll venture a theory:

/dev/sdb1 is perhaps swap space?

If something central to the graphical interface has been offloaded to disk, the GUI can't continue until it has received those data. If the swap disk is sleeping, this means it's stuck until the disk responds.

I think this would give a temporary lockup, and the 10-20 second period fits the time it takes for a sleeping disk to respond. The terminal is presumably still responsive because all it needs is already in RAM.

Some terminal tools to explore the theory:

  • hdparm -C /dev/sdX tells you whether a disk is sleeping:

    $ sudo hdparm -C /dev/sdb
    drive state is:  standby

    active/idle means that it's running. In state standby or sleeping it has stopped spinning and will take a while to start up again. See man hdparm.

  • free -m says how much swap space is used:

    $ free -m     
                 total       used       free     [...]
    Mem:          5973       4928       1045     [...]
    -/+ buffers/cache:       1091       4882
    Swap:         6234          0       6234

    "Swap:" is the relevant line, in this example 6.2 GB swap is available and nothing is used.

If this is the issue, you could either move swap to sda or disable spindowns for sdb.

share|improve this answer
This is a good theory, but I think the problem isn't related to swap. While the swap partition is indeed on the same drive, the system rarely, if ever, uses it. free -m during the lockup confirmed that 0 MB of swap was being used. – ændrük Mar 15 '11 at 1:06
@ændrük Ok, then I'll have to leave the field to the experts. – j-g-faustus Mar 15 '11 at 1:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.