2

The external hard disks attached to my Raspberry Pi spin up seemingly randomly and I don't know why. They form a RAID 1 managed by mdadm whose only partition is formatted with ext4.

Today, I set up a screen running

$ while true; do inotifywait -r /media/raid/; sleep 300; done

and refrained from using my RAID. It didn't monitor a single event the entire time, so no process seems to just randomly access the file system on my RAID.

On a different screen, I ran

# while true; do inotifywait /dev/sd{a,b}* /dev/md1; fuser /dev/sd{a,b}* /dev/md1; sleep 300; done

which recorded many events throughout the day but only a few PIDs. These where from /usr/sbin/smartd -n and /usr/lib/udisks2/udisksd --no-debug which I'm not even sure make the HDDs spin up. The culprits have likely gone unnoticed as they kept the files open only for such a short period of time that it took too long for fuser to be called and produce their PIDs.

How do I find out about the cause of those spin-ups?

In case the suspicion that this is a duplicate is correct, I posted a new question about actually solving the problem.

UTF-8
  • 3,175
  • 5
  • 23
  • 50
  • @StephenKitt The HDDs spin down but don't stay spun-down. Idk whether that tool can help with that if it works because it doesn't on my system: https://pastebin.com/KhYYNHK3 – UTF-8 Dec 03 '17 at 19:06
  • Sorry, the command is different now; you’d probably need to run `iosnoop` without arguments, or choose one of the drives in your RAID and filter on that, using *e.g.* `iosnoop -d 8,16` (look at the values in the output from `ls -l /dev/sd*`). – Stephen Kitt Dec 03 '17 at 19:35
  • @StephenKitt It yielded this output: https://pastebin.com/KcBurcx8 I then ran `sudo iosnoop -d 8,0 -d 8,1 -d 8,16 -d 8,17 -d 9,1` on a screen which printed an empty table and not only didn't fill it with content when one of the HDDs spun up randomly but also not when I made both spin up by creating a new file on the RAID's file system or even writing a lot of data to it by initiating a backup of my laptop which is written to the RAID. – UTF-8 Dec 03 '17 at 20:48
  • You can’t use multiple `-d` options, only the last one counts. In your case, just run `iosnoop` without a filter (and `grep -v` to ignore devices you don’t care about). – Stephen Kitt Dec 03 '17 at 21:00
  • @StephenKitt The questions aren't even similar! – peterh Dec 04 '17 at 00:10
  • 1
    @peterh the underlying question in both cases is “How can I determine what’s causing my drive to spin up?”, so IMO they are related (and `iosnoop` or something similar is a possible solution in both cases). – Stephen Kitt Dec 04 '17 at 05:34

1 Answers1

0

This solution may seem a bit extreme but if you can afford a reboot then you could use an LSM (AppArmor, SELinux) to block every access to both the mount point and the device file. You will find the killed process in the logs then.

You may not even have to block the access if you use the learning mode. But maybe that creates too much log data.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174