How to identify which processes are accessing your disk

If you're wondering why your disk won't spin down, or spins down but wakes up sooner than you thought it should, or why the LED on your flash stick keeps flashing, this page describes how you can identify which processes are responsible.

The debugging feature you need was introduced in kernel version 2.6.6 as part of the laptop-mode patch. If you have an older kernel the feature is not available, unless you have somehow backported the laptop-mode patch. For NSLU2 distributions, this means that:

• Debian / NSLU2 (kernel 2.6.17-2) : supported.
• OpenDebianSlug? (kernel 2.6.12.2) : supported.
• Unslung 6.8 : not supported

(Please add other distributions to this list.)

First, you must modify your syslog.conf to not sync to disk. If you don't do this, your system may get into a feedback loop, where syslogd causes disk activity, this causes kernel output, and this causes syslogd to do more disk activity, etcetera!

How you modify syslog.conf depends on which syslogd is installed. If your '/sbin/syslogd' is a symbolic link to 'busybox' then you really don't have a fully functional syslogd and should follow the 'Busybox syslog.conf' instructions. Everyone else should follow the 'syslog.conf' instructions.

Busybox syslog.conf

First stop the syslogd with the command '/etc/init.d/syslog stop' Then edit '/etc/syslog.conf' and Change the 'DESTINATION' to 'buffer' Restart the syslogd with the command '/etc/init.d/syslog start'

Syslog.conf

In /etc/syslog.conf, you have to place a dash (-) before the log file name, e.g. the line kern.* /var/log/kern.log becomes kern.* -/var/log/kern.log. You then have to either 'kill -HUP' on the syslogd process or start and stop the daemon.

Note that this is not the same as the CONFIG_BLK_DEV_IO_TRACE kernel configuration option.

If you are using a supported kernel, here's how to proceed:

1. As root, echo 1 > /proc/sys/vm/block_dump
2. Wait for the "mysterious" disk activity
3. quickly dmesg > /some/file
4. echo 0 > /proc/sys/vm/block_dump

You can then see what processes are access the disk via the dmesg output. Note: with syslogd changes above which causes it to log to buffers only, there will be no record of syslogd activity in the standard /var/log/messages files.

Basically each line describes one block access. Here's an example:

bash(2695): READ block 600146 on sda1

bash(2695): READ block 600172 on sda1

ls(2695): READ block 600212 on sda1

ls(2695): READ block 702888 on sda1

ls(2695): READ block 702912 on sda1

This shows the name of the executable, the process id, and a description of what changed. The filename accessed is shown in (), e.g. "kern.log" on the first line of the example. In many cases this won't tell you anything especially if you are using a journalling filesystem.