No spin-down via hd-idle after upgrade to 9.1.5

3

3dbruce

New Member
Feb 6, 2026
7
0
1
Hi,
this morning I upgraded to PVE 9.1.5 and kernel 6.17.9-1 on a small DXP2800 NAS. I had initial problems starting one lxc container with a read-only bind-mount but was able to workaround that by removing the read-only flag.

A few hours ago, however I noticed that my hard drives were not spinning down any more when idle for more than 900secs. Apparently the hd-idle service is started normally, but the last entry in my hd-idle.log is from 9:29 right before I started the update to 9.1.5.

I was wondering if that could have been another side-effect of the bind-mount issue and decided to use the other recommended workaround, namely to downgrade pve-container to 6.0.18 (and reinstate the read-only flag in the bind mount). Unfortunately even after another reboot of the pve host, my hard-drives still refuse to spin-down now.

Any idea what is going on here?

Thanks and best regards
- Uwe
 
After rebooting with the old 6.17.4-2-pve kernel, the spin-down is working again. So it seems to be an issue with the new 6.17.9-1-pve kernel.
 
Last edited:
Yep, this is what I had to do as well. So I used the following command until a new kernel release fixes it.
proxmox-boot-tool kernel pin 6.17.4-2-pve

The new kernel has something in it that keeps waking my drives that I put to sleep using hdparm -Y /dev/sdX
so will keep using the previous version until a new version is released that works well. Spent a lot of time disabling smartmontools and other things (/etc/lvm settings?) that in the end had nothing to do with the problem.

Bash: 
# proxmox-boot-tool kernel list
Manually selected kernels:
None.

Automatically selected kernels:
6.17.4-2-pve
6.17.9-1-pve

Pinned kernel:
6.17.4-2-pve
 
After a helpful hint on reddit, I set the debug flag for hd-idle yesterday. I seems that something keeps writing to the drives roughly every 600secs, so my 900 sec timeout is never reached. This also happens even when I shutdown all VMs and containers. I tried to find the process that causes this via iotop and identified a few processes that were always active when the respective writes to my harddisks occur. However none of those look particularly suspicious (at least to me):

Rich (BB code): 
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
  41543 be/4 root        0.00 B/s    7.32 K/s ?unavailable?  [kworker/u16:1-events_power_efficient]
    430 be/4 root        0.00 B/s    6.93 K/s ?unavailable?  systemd-journald
   1418 be/4 root        0.00 B/s  136.37 B/s ?unavailable?  pmxcfs
  57174 be/4 www-data    0.00 B/s  102.28 B/s ?unavailable?  pveproxy worker
    324 be/4 root        0.00 B/s   68.19 B/s ?unavailable?  [txg_sync]

I haven't found a tool yet that lists the process AND the device that is being written to, so I cannot tell which of those is writing to my hard-drives. Hence I am a bit stuck here. For the time being I also pinned the old kernel and wait for a solution.
 
Not sure I understand what you mean exactly. The two harddisks (at /dev/sda and /dev/sdb) form a ZFS mirror and the respective pool contains several datasets which are mounted at /mnt/<poolname>/<datasetname>

EDIT: And to expand a bit further, all of these datasets are used in bind-mounts for various lxc containers (for samba, sftp, plex, etc.). Writes to the disks happen with the new kernel even when all of these lxcs are shutdown, though. I have also not installed any additional services on the pve host itself.
 
Last edited:
When VMs and containers are off, you may use lsof | grep /mnt
(or some more specific option of lsof to avoid grep ).

If some file there is open by some process, lsof will show it.
Of course there might be a situation that a file is not open all the time, just periodically and lsof won't show it in the moment of using it.

Then you can install auditd package and set a filter for logging accesses to selected directories or files.
 
Last edited:
  • Like
Reactions: 3dbruce
Onslow said:
When VMs and containers are off, you may use lsof | grep /mnt
(or some more specific option of lsof to avoid grep ).

If some file there is open by some process, lsof will show it.
Of course there might be a situation that a file is not open all the time, just periodically and lsof won't show it in the moment of using it.

Then you can install auditd package and set a filter for logging accesses to a selected directories or files.
Click to expand...

Thanks a lot! Will try to do that tomorrow (after my nightly jobs are finished and I can reboot with the new kernel again).
 
Good morning! I noticed the same thing on my home system - also a Ugreen DXP2800 NAS. After finding this thread I also downgraded to the 6.17.4-2-pve kernel, and hd-idle seemes to be working again. I can‘t tell for sure because a zfs replication job to a remote site started around midnight, but before that I saw a few hours of the HDDs beeing spinned down.

Proxmox is installed from the official ISO image (so not a self installed debian with proxmox as a additional application) to a zfs mirror of two nvme disks, all VMs are running from those too. The two HDDs, also a zfs mirror, are just used for (rather cold) data storage, only accessed for a hour or two a day. Only service to use those SSDs is samba. Nothing within my VMs or proxmox itself should be using the data on the HDDs, so when all other systems in my house are powered down the HDDs should happily spin down after 20 minutes. And they did so before the latest updates :)

Will continue to monitor the behavior of the two kernel versions and report back.
 
Tried using lsof to hunt for any open files when the disk writes occur but wasn't successful. Without any running VMs/CTs that are even aware of these mounts, I somewhat doubt that a process specifically targets those.

Could the update to ZFS 2.4.0 have something to do with this behavior?
 
3dbruce said:
Could the update to ZFS 2.4.0 have something to do with this behavior?
Click to expand...
Yep, I think you identified the issue. My 2 x HD that wouldn't spin down are an unmounted (backup) zfs mirror that are set with hdparm -Y to sleep. Every ~10 mins would wake up with the new kernel using zfs 2.3.5. See https://github.com/openzfs/zfs/issues/18082 so it's a zfs issue and it looks like a fix is in the pipeline, but no idea when it becomes mainstream.
 
Last edited:
cardre said:
Yep, I think you identified the issue. My 2 x HD that wouldn't spin down are an unmounted (backup) zfs mirror that are set with hdparm -Y to sleep. Every ~10 mins would wake up with the new kernel using zfs 2.3.5. See https://github.com/openzfs/zfs/issues/18082 so it's a zfs issue and it looks like a fix is in the pipeline, but no idea when it becomes mainstream.
Click to expand...
Yes, the description sounds very much that this is the same issue. Good that a fix is already in discussion! Since it's only a very minor annoyance, I'll just pin the old kernel and wait patiently.
 
You must log in or register to reply here.
Top Bottom
Back