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!

Busybox syslog.conf

Syslog.conf

First, you must modify your syslog.conf to not sync to disk. 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.

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.

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.

(Please add other distributions to this list.)

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

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 is a kernel option. It may or may not have been compiled in to the kernel that you're using. Sorry, I don't know what the kernel option is called, does anyone else know?

Please add to the following list:

• OpenDebianSlug? (kernel 2.6.12.2) : supported.
• Unslung 6.8 : not supported

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
5. Examine /some/file

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

syslogd(1026): dirtied inode 89193 (kern.log) on sda1 syslogd(1026): dirtied inode 89333 (debug) on sda1 syslogd(1026): READ block 721938 on sda1 syslogd(1026): dirtied inode 89333 (debug) on sda1 syslogd(1026): dirtied inode 89333 (debug) on sda1 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.