4

TL;DR Is there a way under Linux to know which file access caused an hard disk to spin up?

Full story My laptop has a NVME disk, which contains the operating system and my home dir, and a spinning hard disk, which contains a second home dir which I use to store bulk data that do not fit on the NVME. I believe it is a common arrangement.

One of the nice things is this layout is that when I am not working on the projects that require files on the spinning disk, the disk itself can spin down, saving on energy, battery time, noise, etc. And this happens quite frequently.

However, every now and then the hard disk spins up even if what I am doing in that moment has no clear link with data that are stored there. It is still a consequence of an action done by me, not of a cron script or something else, because it still happens as a consequence of my doing something, like opening an application. However I cannot see what opening that application should produce an access to the spinning disk, knowing which file are supposed to be there. So I would like to understand more of what happens, and this justifies the question above.

Giovanni Mascellani
  • 459
  • Technically that question is on how to prevent spinning up, while mine is how to diagnose what is causing the spinning up. I admit that they are very related. – Giovanni Mascellani Feb 20 '19 at 18:02
  • The answer explains how to trace the origin of disk activity. – Stephen Kitt Feb 20 '19 at 19:05
  • Ok. Is it possible to mark the question as duplicate or already answered, while at the same time copying my own answer to the other question? I found a different answer, and I think it might be useful to keep it. – Giovanni Mascellani Feb 21 '19 at 09:30
  • It should be possible, I’ve asked a moderator to do so. (Non-moderators can mark the question as already answered, but can’t move the answer. You could move your answer manually, by deleting it here and adding it to the target question, but you’d lose your upvote.) – Stephen Kitt Feb 21 '19 at 09:34

1 Answers1

2

EDIT After some time I discovered there is a nice utility called fatrace that makes everything easier because you do not have to mess with services and devices: just call fatrace and you will see a log of all file accesses going on. If you want to see only a certain device, just grep its mount point, or change dir to the mount point and use the -c flag.

auditd can be used to monitor Linux syscalls, and it support filtering according to the involved device. The following instructions are for a Debian system, but others will probably be very similar.

First install and start auditd:

# apt-get install auditd
# service auditd start

Then find the major and minor device number of the device you want to monitor, /dev/sda in my case:

# ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 feb 17 09:58 /dev/sda

So 8 is the major and 0 is the minor. At last, create and auditd rule like this:

# auditctl -a always,exit -F devmajor=8 -F devminor=0

Now look at /var/log/audit/audit.log, where all file accesses will be logged. This might help to find which process is causing the hard disk to spin up.

The log is probably very verbose and might fill up the disk quite quickly. Once you're done, you can shut down auditd:

# service auditd stop
Giovanni Mascellani
  • 459
  • I'm not familier with this tool, and acorrding to you it logs Linux syscalls, but as long as I know there is no syscall for spining the disk... When the OS noticed that the page or section of the wanted data is not in the main memory it brings it from the device using its driver, and its the internal device hardware that determine if to spin the disk. Am I wrong? – Z E Nir Feb 20 '19 at 08:02
  • 1
    Yes. The point of my answer is to understand what syscall caused the data to be fetched in the first place. – Giovanni Mascellani Feb 20 '19 at 18:03