How to find which process is regularly writing to disk?

Question

How can I find which process is constantly writing to disk?

I like my workstation to be close to silent and I just build a new system (P8B75-M + Core i5 3450s -- the 's' because it has a lower max TDP) with quiet fans etc. and installed Debian Wheezy 64-bit on it.

And something is getting on my nerve: I can hear some kind of pattern like if the hard disk was writing or seeking someting (tick...tick...tick...trrrrrr rinse and repeat every second or so).

In the past I had a similar issue in the past (many, many years ago) and it turned out it was some CUPS log or something and I simply redirected that one (not important) logging to a (real) RAM disk.

But here I'm not sure.

I tried the following:

ls -lR /var/log > /tmp/a.tmp && sleep 5 && ls -lR /var/log > /tmp/b.tmp && diff /tmp/?.tmp

but nothing is changing there.

Now the strange thing is that I also hear the pattern when the prompt asking me to enter my LVM decryption passphrase is showing.

Could it be something in the kernel/system I just installed or do I have a faulty harddisk?

hdparm -tT /dev/sda report a correct HD speed (130 GB/s non-cached, sata 6GB) and I've already installed and compiled from big sources (Emacs) without issue so I don't think the system is bad.

(HD is a Seagate Barracude 500GB)

Solution 1

Did you tried to examin what programs like iotop is showing? It will tell you exacly what kind of process is currently writing to the disk.

example output:

Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    8 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
 1033 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [flush-8:0]
   10 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/1]

Solution 2

You can enable IO debugging via echo 1 > /proc/sys/vm/block_dump and then watch the debugging messages in /var/log/syslog. This has the advantage of obtaining some type of log file with past activities whereas iotop only shows the current activity.

Solution 3

You can wack on this a bit. Should narrow it down for most.

find / -mount -newer /proc -print

Give files modified since boot on the physical device of the / files system. Knowing the files will likely help identify the writer.

Solution 4

Assuming that the disk noises are due to a process causing a write and not to some disk spindown problem, you can use the audit subsystem (install the auditd package). Put a watch on the sync calls and its friends:

auditctl -S sync -S fsync -S fdatasync -a exit,always

Watch the logs in /var/log/audit/audit.log. Be careful not to do this if the audit logs themselves are flushed! Check in /etc/auditd.conf that the flush option is set to none.

If files are being flushed often, a likely culprit is the system logs. For example, if you log failed incoming connection attempts and someone is probing your machine, that will generate a lot of entries; this can cause a disk to emit machine gun-style noises. With the basic log daemon sysklogd, check /etc/syslog.conf: if a log file name is not be preceded by -, then that log is flushed to disk after each write.

Solution 5

It might be your drives automatically spinning down, lots of consumer-grade drives do that these days. Unfortunately on even a lightly loaded system, this results in the drives constantly spinning down and then spinning up again, especially if you're running hddtemp or similar to monitor the drive temperature (most drives stupidly don't let you query the SMART temperature value without spinning up the drive - cretinous!).

This is not only annoying, it can wear out the drives faster as many drives have only a limited number of park cycles. e.g. see https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/952556 for a description of the problem.

I disable idle-spindown on all my drives with the following bit of shell code. you could put it in an /etc/rc.boot script, or in /etc/rc.local or similar.

for disk in /dev/sd? ; do
  /sbin/hdparm -q -S 0 "$disk"
done

View more solutions

Comments

[Admin]

Are you sure it's a hard drive making that noise, and not something else? (Check the fans, including PSU fan. Had very strange clicking noises once when a very thin cable was too close to a fan and would sometimes very slightly touch the blades and bounce for a few "clicks"...)

[Admin]

@Mat: I'll take the hard drive outside of the case (the connectors should be long enough) to be sure and I'll report back ; )

[Admin]

Make sure your disk filesystems are mounted relatime or noatime. File reads can be causing writes to inodes to record the access time.

[Cedric Martin]

thanks for that tip. I didn't know about iotop. On Debian I did an apt-cache search iotop to find out that I had to apt-get iotop. Very cool command!

[Cedric Martin]

that you can't query SMART readings without spinning up the drive leaves me speechless :-/ Now obviously the "spinning down" issue can become quite complicated. Regarding disabling the spinning down: wouldn't that in itself cause the HD to wear out faster? I mean: it's never ever "resting" as long as the system is on then?

[Alessio]

IIRC you can query some SMART values without causing the drive to spin up, but temperature isn't one of them on any of the drives i've tested (incl models from WD, Seagate, Samsung, Hitachi). Which is, of course, crazy because concern over temperature is one of the reasons for idling a drive. re: wear: AIUI 1. constant velocity is less wearing than changing speed. 2. the drives have to park the heads in a safe area and a drive is only rated to do that so many times (IIRC up to a few hundred thousand - easily exceeded if the drive is idling and spinning up every few seconds)

[beachCode]

It is absolutely crazy to leave sysloging enabled when block_dump is active. Logging causes disk activity, which causes logging, which causes disk activity etc. Better stop syslog before enabling this (and use dmesg to read the messages)

[hayath786]

You are absolutely right, although the effect isn't as dramatic as you describe it. If you just want to have a short peek at the disk activity there is no need to stop the syslog daemon.

[beachCode]

I've tried it about 2 years ago and it brought my machine to a halt. One of these days when I have nothing important running I'll try it again :)

[hayath786]

I tried it, nothing really happened. Especially because of file system buffering. A write to syslog doesn't immediately trigger a write to disk.

[Volker Siegel]

I would assume there is rate general rate limiting in place for the log messages, which handles this case too(?)

[Micheal Johnson]

It's a long debate regarding whether it's better to leave drives running or to spin them down. Personally I believe it's best to leave them running - I turn my computer off at night and when I go out but other than that I never spin my drives down. Some people prefer to spin them down, say, at night if they're leaving the computer on or if the computer's idle for a long time, and in such cases the advantage of spinning them down for a few hours versus leaving them running is debatable. What's never good though is when the hard drive repeatedly spins down and up again in a short period of time.

[Micheal Johnson]

Note also that spinning the drive down after it's been idle for a few hours is a bit silly, because if it's been idle for a few hours then it's likely to be used again within an hour. In that case, it would seem better to spin the drive down promptly if it's idle (like, within 10 minutes), but it's also possible for the drive to be idle for a few minutes when someone is using the computer and is likely to need the drive again soon.

[Micheal Johnson]

It's only going to flush data if there's any data to flush. If the disk is really not in use, then there isn't going to be any buffered data to flush.

[lzap]

You can configure smart daemon not to scan USB disks, most good linux distributions do this by default.

[Michael]

I thought sure this would fix my issue as I hear the drive make a periodic clacking sound (3-4 times/second) like it's writing even when it's not mounted! But I still hear the noise after running this command. Worryingly, it's the drive I use to back up my internal SSD...

[Lion]

I have a ZFS pool and the kernel log is on the system SSD, so no recursive activity. But for some activites I cannot see the process: Jun 1 07:43:13 nas kernel: [44479.254095] z_wr_iss(769): WRITE block 9663902944 on sda1 (8 sectors) What does z_wr_iss mean? My disk got waked up by those write.

[hayath786]

@Lion This belongs to a new question. Anyway, z_wr_iss is a kernel thread for the ZFS file system. Further details are not known to me.

[Fmstrat]

A variant of this that worked best for me was: rm -f a; touch a; sleep 30; find / -mount -newer a -print |less

[Sam Sirry]

I guess this tests for the moment the command is run. How do I get it to monitor over a period of time, like, say, 10 seconds?

[Sam Sirry]

I found it: jrs-s.net/2019/06/04/continuously-updated-iostat

[krubo]

Unfortunately on new systems it mostly just shows jbd2 as everything goes via the journal