I have a 24/7 always-on Debian Jessie based headless home server that has a large 1TB SSD for the OS and all of my frequently accessed files. This same system has 4 larger hard disk drives in a SnapRAID array. These are mainly for archiving infrequently accessed Blu-rays and want those drives to remain spun down in standby unless I actually read or write to them. They are all formatted as ext4 and mounted with noatime and nodiratime enabled.

So even though no process or program should be regularly accessing those drives in any direct way, the hard drives constantly get spun up from standby. It seems to be related to graphical programs that provide a gui file browser, even something like Chromium. If I don't even browse into those drives, I'm thinking that these processes by simply getting a list of available drives spins up the hard disks. Much like blkid does. The problem is, it's hard to determine the root cause of this since none of these processes are actually reading or writing the filesystem on those drives, so no files are actually changing or being touched. Is there some sort of cache that I can populate or a buffer to prevent these programs from spinning up the hard drive simply by getting a list of available disks? This is honestly driving me insane, since I can't find a reliably way to keep these disks spun-down even though there is no direct access of the filesystem.

UPDATE: Thanks to Stephen's answer, I was able to trace the disk activity to gvfs and udisks. It's a real shame that these processes insist on waking up disks in standby when they aren't actually being accessed to do any real I/O with the filesystem. So far I just uninstalled them, knowing that it will remove some functionality from PCManFM and the like.

  • 1
    pretty nearly any access of most drives will wake them up from idle, even smartctl queries to check the temperature or check the idle state. yes, this is stupid. blame the stupid firmware in most drives. Note that constantly spinning a drive down and up and up again can wear it out, as most drives have a limited number of times they can be 'parked'. safer to just disable idle spindown entirely. e.g. see unix.stackexchange.com/questions/44103/…
    – cas
    Apr 4, 2016 at 8:31

2 Answers 2


You can use blktrace (available in Debian) to trace all the activity to a given device; for example

sudo blktrace -d /dev/sda -o - | blkparse -i -

or just

sudo btrace /dev/sda

will show all the activity on /dev/sda. The output looks like

  8,0    3       51   135.424002054 16857  D  WM 167775248 + 8 [kworker/u16:0]
  8,0    3       52   135.424011323 16857  I  WM 209718336 + 8 [kworker/u16:0]
  8,0    3        0   135.424011659     0  m   N cfq496A  / insert_request

The fifth column is the process identifier, and the last one gives the process name when there is one.

You can also store traces for later analysis; blktrace includes a number of analysis tools such as the afore-mentioned blkparse and btt. blktrace is a very low-level tool so it may not be all that easy to figure out what caused activity in the first place, but with the help of the included documentation (see /usr/share/doc/blktrace if you installed the Debian package) and the blktrace paper it should be possible to figure out what's causing the spin-ups.

  • thank you. this allowed me to confirm my suspicion that it is related to applications that provide a file browser, as udisksd was the culprit. Now I just need to investigate into how I can work around udisks's incompetence. Apr 4, 2016 at 17:04
  • This is precisely what I was looking for. Thank you, Stephen Kitt. I will try it out right away.
    – neverMind9
    Jul 10, 2018 at 1:41
  • Where are all colums of btrace documented?
    – neverMind9
    Jul 12, 2018 at 0:36

Do try strace.

strace -f -e open ls

The above command should list out all disk activity related to open methods, which you suspect are responsible for causing your disk spinups.

Alternatively, dmesg might give you some information on physical disk mounts/unmounts.

This site has a pretty good guide on using strace to monitor disk activity.

As for populating a cache to stop disk IO I doubt that's possible, but I may be wrong.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.