11

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.

Improve this question
11
  • 1
    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, 2011 at 18:01
  • Is this a laptop, by the way?
    – j-g-faustus
    Mar 13, 2011 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, 2011 at 19:52
  • Could be a bad disk, check SMART data or output of dmesg for disk errors.
    – arrange
    Mar 13, 2011 at 22:43
  • 4
    "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, 2013 at 21:55

1 Answer 1

Reset to default
4

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

Improve this answer
2
  • 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, 2011 at 1:06
  • @ændrük Ok, then I'll have to leave the field to the experts.
    – j-g-faustus
    Mar 15, 2011 at 1:14

Not the answer you're looking for? Browse other questions tagged .