HDD spinning up every 10min

Support Kernel
1

Hi there,
since the Testing Update 2021-10-05, i notice one of my HDDs is spinning up now and then.
According to dmesg it seems to be pretty much exactly every 600s.
dmesg:

[ 6021.367611] ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 6021.369207] ata9.00: configured for UDMA/133
[ 6021.369285] sd 8:0:0:0: [sda] Starting disk
[ 6047.567109] sd 8:0:0:0: [sda] Synchronizing SCSI cache
[ 6047.567373] sd 8:0:0:0: [sda] Stopping disk

Only happens for sda it seems, sdb is the exact same hdd model on the same controller.
I tried to catch if any process is trying to access the data there, but no luck so far with lsof and iotop.
I wasn’t able to find anything useful in that regard unfortunately, so i hope someone here has some idea on how to troubleshoot?

2

Check your /etc/fstab. Maybe you have something like

commit=600

in the line defining the mounting parameter for the device. This would sync the disc every 600 sec.

3

fstab: /dev/mapper/data /media/data ext4 defaults,nofail,x-systemd.device-timeout=30 02
crypttab: data UUID=xxx /crypto_keyfile.bin luks,timeout=90

Unless defaults have changed (and in that case the other hdd should show the same behaviour?) that doesn’t seem to be the cause, no :confused:

4

It’s fine for me use it on nvme and SATA SSD without issues.

5

Another idea: may be the the same HDD models has different FW used?

smartctl --scan

and then

sudo smartctl -a /dev/...

for each.

Does kernel version matters (5.14, 5.13, 5.10, 5.4, 5.15-rcX)?

6

Firmware is the same on both according to smartctl (they have been bought together, so i’d have assumed as much, but you are right that checking is always better ^^)

Kernel doesn’t seem to matter, at least not between 5.14 and 5.15rc3-rc5. I might have switched to 5.15rc3 after the 10-05 update, but i’m not 100% sure. Only thing slightly different on 5.14 is that it’s not exactly 600s but more like 580s.

7

What type of setup is this? Are any logs involved? Any RAID involved?

What models / FW are these, by chance?

There could also be a task that is “polling” the drive in question, even though no data is being written to it nor read from it.

1 Like
8

Could it be a file indexer spinning it up to check for changes? Like Baloo on KDE.

3 Likes
9

It is there:

image
image1038Ă—240 33.2 KB

1 Like
10 
Device Model:     WDC WD40EFRX-68N32N0
Firmware Version: 82.00A82

Any idea on how to find out which task might be polling or doing anything else?
It isn’t balloo, that’s limited to home. I’ve excluded the affected drive anyway, lets see if that helps regardless.

11

I insist to turn off the indexing completely (to remove corresponded flag in the checkbox and after that to check it by balooctl status output: Baloo is currently disabled. To enable, please run balooctl enable): the /home/user_name folder can’t be ignored in current KDE version: 429910 – Settings -> File search: Folder specific configuration list: self-reproducing, irremovable items of '/home/<username>' with 'indexed' value for some period of time. It is known (by KDE team) lack.

List timer units currently in memory, ordered by the time they elapse next:

systemctl list-timers -all
1 Like
12

Is this a desktop that is always powered on?

If so, I would recommend disabling any sleep/spindown options for the Red Plus drives, as it would serve them best for performance and longevity.

Is there a reason you want them to spindown and spinup? While idle, the power consumption for such drives spinning 24/7 is negligible.

Red, Red Plus, and "white label’ enterprise drives (from shucking) are designed to run 24/7.

13

It’s not always on, no - and both disks are very rarely used (one is for backup, so basically only on update and every three days, the other one is for bulk storage, so only accessed occasionally) - besides that, the noise would be annoying ^^

With disabled (and verified by balooctl status) baloo, it is still happening :confused:

14

So all drives, including the two Red Pluses, spindown and power down every time you suspend or turn off your PC. This would fall under “not being accessed or used”.

It might work better to use some sort of auto-mount / systemd unit to dynamically mount and unmount the file-systems on the drives. This way, if it resolves the problem, you’re good to go. However, if it does not, it will clue you into the possibility that something is trying to accessing the hardware itself and not necessarily data on the mount points.

UPDATE: Why not manually unmount both drives for the next hour or so? You won’t have access to the “data”, but you will gauge if the drive(s) spins up, even while nothing is mounted.

This might help steer you towards finding a solution if it resolves the rhythmic 10-minute wakeups.

15

I don’t know if the drives really spin up on every boot, at least i don’t remember hearing it spinning up.

Your suggestion with unmounting is indeed a good one - it can’t be unmounted because it’s in use. Now the question remains how i can find out what is the cause for that.

16

You can check with:

lsof | grep /path/of/mount

My money is on KDE’s Dolphin holding on to something. Ugh, I’m telling you, Dolphin has been getting buggier with each new update. Every time there’s a new bug with Dolphin/KIO, they fix it… and then another new bug takes its place. :expressionless:

17

Like i wrote in my initial post that was my first try to find out - unfortunately, it still returns nothing :confused:

18

Doesn’t hurt to try closing all Dolphin instances and then,

killall dolphin

Then see if you can unmount the drives.

19

unfortunately not, no

20

What are the most recent messages from dmesg immediately after a failed unmount attempt?

sudo dmesg | tail -n 50