Identifying process responsible for disk writes every 4 seconds
 

I've set up Slackware 12.1 on a fanless fit-pc (not advertising, just background :)) and I've got NFS and SAMBA working on it beautifully. However, at the moment, it's not quite silent as I can hear the hard drive writing something every 4 seconds, confirmed by the output of this sar command:There's nothing in /var/log/messages that's that frequent. The only other things running on the server are wicd (for the wireless) and a vncserver. Disabling the VNC server doesn't stop the disk writes.

How can identify what process is accessing the disk that periodically?

You could use `atop' and order the display by disk activity

Not with Slackware you can't. Slackware doesn't come with atop. It has 'top' but there's no way to order by disk activity. This problem has been asked about before. One thread I've managed to find is here which may be useful. There have been others but I can't find them straight off but remember the overall opinion was that it was tricky to track down.

Always possible to download and compile it yourself.

See http://www.atcomputing.nl/Tools/atop/download-atop.html

I've had a look at atop, and there's a SlackBuild for it on SlackBuilds.org, but it requires patching the kernel sources before compiling in order to get disk and network I/O stats. I can use powertop with a custom kernel too to identify processes using the most power. Since this machine is idle during these disk accesses, whatever process is responsible for the disk writes will also be the one using the most power, and will therefore show up on powertop. However, I wanted to avoid compiling my own kernel, if I could :)

Although, I suppose this provides a good excuse to!

Lots of caveats there. Be sure you keep your current or previous kernel installed and workable before proceeding.

While I haven't got a perfect answer for you, I did once have a similar problem. For me, it was a networking problem (DHCP, if I recall and not getting back from the rest of the network what was expected) but whether that is of any help is doubtful.

I think the easiest attack is probably a bit 'brute force and dumb'. Check all of the log files. Is, for example, dmesg growing? You might be able to script something loking at mtime (or even atime, if that's still on) to look for files that are beinmg accessed frequently, but I found that as I had a super-adequate supply of dumb-ness, that wasn't totally necessary.

If you only have top, you can look for processes that spike up in activity (partic if IO wait spikes up).

I'm sure that once you get a clue as to what is going on, you'll slap your forehead and go 'why did it take me so long to realise that this is what would happen?' :D

(The good news is that, even leaving this on for several months, 24/7, before actually getting my act together to actually do something about the problem, the disk drive is still fine, thank you.)

Well, I upgraded to 12.2 and thought that'd fixed it, but it's back again. I was also running a VNC server on this server, so I killed that, and I don't get the spikes in the sar command anymore. But, it's late, and I'm not sure if I can still hear the drive ticking away, but fingers crossed it's gone!

I once had a similar issue so might be useful to post here:

Mine was because I was running the little KTrafficAnalyzer package which was regularly writing to a 'log' file so that historical network traffic could be viewed. In my case the only way I found to stop this was to make the appropriate data file 'read-only'.

It might be some application similar to this.

I can't remember now how I tracked it down.

Bill.

The VNC server was running a full XFCE desktop, which for me includes GKrellM monitoring all my partitions and disks, as well as CPU usage and temperatures etc., so I'm almost certain it's that which was writing to disk. Either way, I've always got sshd running on the server, and I have to ssh in to forward the appropriate ports anyway, so I'll just launch the VNC server explicitly every time I want to use it. I'd rather do this than listen to that infernal hard drive ticking!

Try blktrace - haven't used it recently, but it will have the data you want.

I just launched a new VNC server (complete with GKrellM), did the sar command and got the same results as before. After killing GKrellM, the 4 second interval spikes in the sar command disappeared, so it was definitely GKrellM that was writing to somewhere, although I've no idea where. I've replaced GKrellM with the relevant XFCE Goodies packages and the sar command is quiet once more.

I couldn't find blktrace on Slackware nor on SlackBuilds.org, but its man page suggests it's what I would have wanted. Thanks.

Maybe you will find some useful info here :

http://www.linuxquestions.org/questi...-drive-603976/

What kernel are you running on your Slackware installtion? Is it the generic kernel or the huge kernel? I've just built and installed blktrace, but I get an error:This thread on the Ubuntu forums suggests I need to recompile my kernel to include CONFIG_BLK_DEV_IO_TRACE as a config option. Thus, I was wondering if the huge kernel already had this, otherwise I'll have to finally get around to rolling my own kernel, which it's high time I learnt how to do anyway. Or is it libaio that I need to install first?

I use a custom kernel with CONFIG_BLK_DEV_IO_TRACE and so on.