Avoid periodical HDD wake up?

[Massimo B.]

Hi,

installed a new setup with SSD and a bit rotating HDD for backups (purchased as used). I'm on OpenRC. Currently the HDD is not partitioned, not formatted, not mounted, showing up as:

Code: Select all

# fdisk -l /dev/sda
Disk /dev/sda: 16,37 TiB, 18000207937536 bytes, 35156656128 sectors
Disk model: TOSHIBA MG09ACA1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: C911E84A-937C-42C1-82E1-FA0A828EF0A0

I planned to have it most of the time sleeping with spin-down, only starting for daily or weekly backups.

But it is continuously waking up with spin up and then going to sleep again every few minutes, syslog shows this:

Code: Select all

Apr 11 11:29:23 [kernel] [14520.637846] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Apr 11 11:29:23 [kernel] [14520.641188] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Apr 11 11:29:23 [kernel] [14520.664002] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Apr 11 11:29:23 [kernel] [14520.683254] ata1.00: configured for UDMA/133
Apr 11 11:29:23 [kernel] [14520.683436] ata1.00: Entering active power mode
Apr 11 11:29:33 [kernel] [14530.731040] ata1.00: qc timeout after 10000 msecs (cmd 0x40)
Apr 11 11:29:33 [kernel] [14530.731073] ata1.00: VERIFY failed (err_mask=0x4)
Apr 11 11:29:33 [kernel] [14530.731083] ata1.00: failed to enable DIPM, Emask 0x40
Apr 11 11:29:38 [kernel] [14534.854526] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Apr 11 11:29:38 [kernel] [14534.873340] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Apr 11 11:29:38 [kernel] [14535.497097] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Apr 11 11:29:38 [kernel] [14535.516985] ata1.00: configured for UDMA/133
Apr 11 11:29:38 [kernel] [14535.517393] sd 0:0:0:0: [sda] Starting disk
Apr 11 11:29:38 [kernel] [14535.526227] sd 0:0:0:0: [sda] Starting disk
Apr 11 11:29:38 [kernel] [14535.534294] sd 0:0:0:0: [sda] Starting disk
Apr 11 11:29:57 [kernel] [14554.274951] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Apr 11 11:29:57 [kernel] [14554.275408] sd 0:0:0:0: [sda] Stopping disk

How can I find the culprit? I already disabled potential services like smartd doing periodical self-tests. Also stopped hd-idle.
AFAIK I don't have any panel widgets doing disk usage or whatever which anyway would apply to mounted filesystems only.

Code: Select all

hdparm -B /dev/sda

/dev/sda:
 APM_level	= 128

How can I freeze the HDD until I solved that, for not aging the HDD too much until getting solved in some weeks? Most of the StartStop counts are done by me without using it:

Code: Select all

# smartctl -a /dev/sda |grep _Count
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       485
 10 Spin_Retry_Count        0x0033   100   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       58
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       18
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       642
196 Reallocated_Event_Count 0x0033   100   100   010    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       14
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0

Ok, the other way round, for now I try to get it spinning without spin-down:

Code: Select all

# hdparm -B 255 /dev/sda

/dev/sda:
 setting Advanced Power Management level to disabled
 APM_level	= off

# hdparm -S 0 /dev/sda

/dev/sda:
 setting standby to 0 (off)

But it still does a spin-down and needs to spin-up for every fdisk -l or something.

Code: Select all

# smartctl /dev/sda -g aam -g apm -g lookahead -g security -g wcache -g rcache -g dsn
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.16-gentoo-dist] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

AAM feature is:   Unavailable
APM feature is:   Disabled
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Disabled
ATA Security is:  Disabled, frozen [SEC2]

[Massimo B.]

Checking custom udev rules:

Code: Select all

# grep -r "sd" /etc/udev/rules.d/
/etc/udev/rules.d/50-usb_drive.rules:KERNEL=="sd*", ACTION=="add", ATTRS{serial}=="3693070883579247478", RUN+="/usr/local/bin/1dmcrypt open %N"
/etc/udev/rules.d/50-usb_drive.rules:KERNEL=="sd*", ACTION=="remove", ATTRS{serial}=="3693070883579247478", RUN+="/usr/local/bin/1dmcrypt close %N"
/etc/udev/rules.d/00-ssd-scheduler.rules:ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{device/model}=="SD/MMC", ATTR{queue/rotational}="0"
/etc/udev/rules.d/00-ssd-scheduler.rules:ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/iosched/slice_idle}="0"
/etc/udev/rules.d/00-ssd-scheduler.rules:ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="kyber" 
/etc/udev/rules.d/00-ssd-scheduler.rules:ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

For now I got it temporarily disabled by

echo 0 > /sys/block/sda/device/delete

[Massimo B.]

I still cannot find the culprit, why this HDD is continously spinning down and up every ~30 seconds. Can I somehow track the access to the device via lsof or something?
for testing I'm going to disable all powersaving (APM) and

Code: Select all

fdisk -l /dev/sda |grep model
Disk model: TOSHIBA MG09ACA1

Code: Select all

hdparm -B 255 /dev/sda
/dev/sda:
 setting Advanced Power Management level to disabled
 APM_level	= off

Code: Select all

hdparm -S 0 /dev/sda
/dev/sda:
 setting standby to 0 (off)

I wonder that after these settings the device is still spinning down every few minutes, hd-idle is not running:

Code: Select all

pgrep -alf hd-idle || echo NO
NO

Can smartctl configure something else addionally? At least it looks like APM is disabled there as well:

Code: Select all

smartctl -g apm /dev/sda
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-6.12.38-gentoo-dist] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
APM feature is:   Disabled

Load_Cycle_Count is increasing on every spin-down:

Code: Select all

smartctl -a /dev/sda |grep Cycle
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       109
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1044

Now before trying to find out who is waking up the HDD all the time, why does it still spin-down after all power management is disabled?

smartctl -a shows a lot of errors right after the Attributes list:

Code: Select all

SMART Error Log Version: 1
ATA Error Count: 14 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 14 occurred at disk power-on lifetime: 17122 hours (713 days + 10 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 68 87 50 56 40  Error: ICRC, ABRT at LBA = 0x00565087 = 5656711

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 68 80 50 56 40 00  22d+18:42:03.550  WRITE FPDMA QUEUED
  60 90 60 c0 7c 7a 40 00  22d+18:42:02.050  READ FPDMA QUEUED
  60 08 58 b8 7c 7a 40 00  22d+18:42:02.050  READ FPDMA QUEUED
  60 08 50 b0 7c 7a 40 00  22d+18:42:02.049  READ FPDMA QUEUED
  60 08 48 a8 7c 7a 40 00  22d+18:42:02.047  READ FPDMA QUEUED

Error 13 occurred at disk power-on lifetime: 17106 hours (712 days + 18 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 b0 87 80 60 40  Error: ICRC, ABRT at LBA = 0x00608087 = 6324359

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 b0 80 80 60 40 00  22d+03:06:46.282  WRITE FPDMA QUEUED
  60 40 a8 20 8f 57 40 00  22d+03:06:46.282  READ FPDMA QUEUED
  aa aa aa aa aa aa aa ff  22d+03:06:45.792  [RESERVED]
  60 40 48 40 e3 74 40 00  22d+03:06:16.297  READ FPDMA QUEUED
  60 40 40 60 45 c9 40 00  22d+03:06:16.297  READ FPDMA QUEUED
...

...and a lot more...
Next point, mounting. The device does not get umounted, I usually also like to have spin-down while mounted. BUT I always mount everything except rootfs via autofs with a timeout, to have network mounts or usb devices getting umounted if not needed. The same I also do for the local backup HDD:

Code: Select all

grep local /etc/autofs/auto.master 
/mnt/autofs/local   /etc/autofs/auto.local  --timeout=600   --ghost 

Code: Select all

cat /etc/autofs/auto.local
data   -fstype=btrfs,compress=zstd:9,subvol=/     LABEL=localdata

Now I wonder why it only got mounted at startup this morning and never got umounted after timeout, it seems to be in use by something:

Code: Select all

grep automount /var/log/everything/current  |grep local.*data
Aug 22 07:50:00 [automount] attempting to mount entry /mnt/autofs/local/data
Aug 22 07:50:00 [automount] mount(generic): calling mount -t btrfs -o compress=zstd:9,subvol=/ LABEL=localdata /mnt/autofs/local/data
Aug 22 07:50:19 [automount] mount(generic): mounted LABEL=localdata type btrfs on /mnt/autofs/local/data
Aug 22 07:50:19 [automount] mounted /mnt/autofs/local/data

Now the syslog sequence when the HDD gets woken up:

Code: Select all

Aug 22 12:19:58 [kernel] [16323.670693] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Aug 22 12:19:58 [kernel] [16323.673766] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Aug 22 12:19:58 [kernel] [16323.694378] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Aug 22 12:19:58 [kernel] [16323.712410] ata1.00: configured for UDMA/133
Aug 22 12:19:58 [kernel] [16323.712532] ata1.00: Entering active power mode
Aug 22 12:20:09 [kernel] [16333.856655] ata1.00: qc timeout after 10000 msecs (cmd 0x40)
Aug 22 12:20:09 [kernel] [16333.856687] ata1.00: VERIFY failed (err_mask=0x4)
Aug 22 12:20:09 [kernel] [16333.856695] ata1.00: failed to enable DIPM, Emask 0x40
Aug 22 12:20:13 [kernel] [16337.826709] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Aug 22 12:20:13 [kernel] [16337.843505] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Aug 22 12:20:13 [kernel] [16338.372615] ata1.00: ACPI cmd f5/00:00:00:00:00:e0(SECURITY FREEZE LOCK) filtered out
Aug 22 12:20:13 [kernel] [16338.391841] ata1.00: configured for UDMA/133
Aug 22 12:20:13 [kernel] [16338.392247] sd 0:0:0:0: [sda] Starting disk
Aug 22 12:20:13 [kernel] [16338.393360] sd 0:0:0:0: [sda] Starting disk
Aug 22 12:20:13 [kernel] [16338.396650] sd 0:0:0:0: [sda] Starting disk
Aug 22 12:20:32 [kernel] [16357.143047] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Aug 22 12:20:32 [kernel] [16357.143406] sd 0:0:0:0: [sda] Stopping disk

However if I trigger a spin-up by accessing the HDD manually, the startup/spin-down sequence looks identical.
I wonder that even a

Code: Select all

hdparm -C /dev/sda
/dev/sda:
 drive state is:  active/idle

does spin up the device. Shouldn't it just report if the device is active or in spin-down? Because I didn't notice all the frequent ups/downs on this remote machine if not sitting in front of it and hearing the startups.

[Goverp]

Dunno if this link is helpful:
https://forum.manjaro.org/t/hdd-spinnin ... d/107462/2
It goes on about autosuspend delay.

[Massimo B.]

Weird I never heard about that:

Code: Select all

echo -1 > /sys/block/sda/device/power/autosuspend_delay_ms

... made the HDD not spin-down anymore. Thanks.
Reading about that in https://www.kernel.org/doc/Documentatio ... gement.txt it only mentions USB devices. Is that a generic kernel option for every device? How does it cohere with APM and hdparm -S spindown timeout? Is that device dynamic PM as described at kernel.org not respected by all HDDs to spindown accordingly?
It was 15000 set by default here. The default as in the docs is 2000. I don't think HDDs are meant to spin-down after every 2 seconds by default?

[NeddySeagoon]

Massimo B.,

Code: Select all

echo -1 > /sys/block/sda/device/power/autosuspend_delay_ms

sets a kernel feature.

Code: Select all

hdparm ...

reads and writes settings that are internal to the HDD.

[Massimo B.]

That leads to a list of questions, beside "Which one is better?"... Actually letting the kernel decide sounds better for more control, but it doesn't work properly. And I guess it's better to only set power management internal in the HDD OR in the kernel, but not both?

• Why don't other HDDs spin-down on that kernel setting?
• All documentation about autosuspend_delay_ms is about USB devices, why does it affect my SATA HDD here?

Is that a special case on that HDD model? What is the recommendation? Which group or mailinglist is better to ask about that?

[Massimo B.]

Coming back to this issue, let me summarize:

I have a local HDD, that runs a btrfs and get's automounted by autofs. It's used for daily backups only and should spin-down the other time.

Nobody knows why, but the kernel setting by default does aggressively spin down this HDD. More serious, any little access seems to wake it up. I found a running Thunar file manager does, a hdparm -c does, a btrfs filesystem usage or a df -h. Even if disabling all that and killing all Filemanagers, the disk was spinning up and down every 5 minutes, heavily increasing the Smart Start_Stop_Count.
So I need to disable it by

Code: Select all

echo -1 > /sys/block/sda/device/power/autosuspend_delay_ms

How can I make that persistent over restarts? /etc/local.d?

Now going to enable the spin-down on the HDD:

Code: Select all

# hdparm -B 1 /dev/sda
/dev/sda:
 setting Advanced Power Management level to 0x01 (1)
 APM_level	= 1

Was accepted and could also spin-down in the maximum Power Management level, but never does a spin-down.

Code: Select all

# hdparm -S8 /dev/sda

/dev/sda:
 setting standby to 8 (40 seconds)

That works. Curiously it also keeps the HDD in spin-down when doing a btrfs filesystem usage. Nice.

[NeddySeagoon]

Massimo B.,

Code: Select all

# hdparm -B 1 /dev/sda 

is more aimed at accustic management than power management.
It sets the acceleration/deceleration for head movements across the platter.
There are really only two settings <=127 and 128..255.
Low power slows head movements so the drive is quieter (and slower) in use.

Code: Select all

Error 14 occurred at disk power-on lifetime: 17122 hours (713 days + 10 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 43 68 87 50 56 40  Error: ICRC, ABRT at LBA = 0x00565087 = 5656711 

That error is an Interface CRC error. That can be a SATA data cable.
Also, it happened at 17122 power on hours. You said the drive was used. Was that before or after you got the drive?
Its trying to read LBA = 0x00565087 = 5656711 but you haven't used the drive yet ... or have you.

I suspect you can recover the original owners data without much effort.

[Massimo B.]

Code: Select all

# hdparm -B 1 /dev/sda 

is more aimed at accustic management than power management.
It sets the acceleration/deceleration for head movements across the platter.
There are really only two settings <=127 and 128..255.
Low power slows head movements so the drive is quieter (and slower) in use.

Really? I had drives supporting Acoustic Management (AAM) (-M) with 2 settings, that made a big difference.
But this drive doesn't and rejects with acoustic = not supported.
I don't hear any difference between -B1 and -B255.

[tlhonmey]

I notice that it's spinning up the drive every 30 seconds, and also that you have the drive formatted with btrfs.

30 seconds is the default commit interval for btrfs filesystems. I believe the commit process will happen whether there have been any actual writes to the drives or not.

You can change the commit interval via mount option and/or remount the drive read-only and see if that changes how often your drives get woken up.

Do note that you will lose everything since the last commit in the event of a power failure, which is why the default is 30 seconds. I think calling sync might force an immediate commit... But it might also just block until the next one. I've never tested it.

You could probably do something with a very long commit interval and then have your backup processes or whatever actually does writes temporarily remount with a short interval. Or if mounting read-only turns off the commit process enough that you don't get extraneous reads you could maybe use that somehow. Depends on what your ultimate goal is I suppose.

[Massimo B.]

commit interval could be the reason. Interesting.
I'm running fine now with a

Code: Select all

echo -1 > /sys/block/sda/device/power/autosuspend_delay_ms

that I do in a /etc/local.d/autosuspend.start.

I'm also umounting the drive via autofs after a timeout, like I do for USB drives, network drives and actually also local drives that are not required all the time. That should stop the commit interval for sure. But the wake up was still there in the past. And how should powersaving by spin down work at all if commit interval is that short. I remember laptop tools in the old days have been increasing the commit interval also for other filesystems when going to powersave/battery mode. Maybe all the spin down and powersaving topics have been vanished into oblivion as SSDs are the new normal in laptops and desktops are not doing powersaving usually. Maybe with a mounted filesystem and commit intervals of 30s, a spin-down would have never been functional in the past.

For now my setup works. If required to do backups, the drive is mounted by autofs, spinning up, and after timeout not being used, it gets umounted and also spinning down after a while.