Boriqueno5

After upgrading to Unraid 7.3.0 the issue improved dramatically. Drives now sleep for ~43 minutes consistently before being woken by a read SMART. The 60-second endless loop is completely gone. The 7.3.0 release notes mention: 'WebGUI and API requests no longer unnecessarily spin up the full HDD array on affected systems.' This appears to have resolved the main issue. A periodic SMART read every ~43 minutes still wakes the drives briefly, but this is acceptable behavior compared to the previous state.

I flashed both ASM1166 controllers to the latest firmware (241224-0000-00) with a full cold boot. Issue persists identically. I also checked the syslog statistics – every single drive has almost identical spinning down and read SMART counts, regardless of which controller they are on. Drives on the onboard Intel AHCI controller show the same pattern as drives on the ASM1166 controllers. Interestingly though, not all drives are equally affected: Seagate IronWolf and WD Red EFRX drives spin down and stay down, while WD Blue (EZRZ/EZRX) and WD Red Plus (EFPX) drives wake up every time. The key difference is APM support – the drives that sleep have APM, the ones that wake up do not. This suggests emhttpd is issuing an ioctl that NAS drives with APM can ignore internally, while desktop drives without APM cannot. Worth noting: the same drives worked fine under a previous setup with different hardware (Gigabyte B760M D3HP instead of DS3H, no M.2 SATA adapter) running the same Unraid 7.2.x version. So the behavior may be hardware-dependent in some way I haven't been able to isolate yet. This rules out the controller firmware as the cause – but I'm open to further suggestions.

Tested both suggestions: maintenance mode (array stopped, no shares) and uninstalling Connect. Issue persists identically in both cases. Drives spin down and are woken by read SMART ~60 seconds later regardless. Interestingly, not all drives are affected equally – some spin down and stay down, while others are woken repeatedly. This would suggest the cause is within emhttpd itself on a hardcoded internal timer, rather than shares, plugins, Docker, or the Connect plugin. Happy to run any further diagnostics if that would help narrow it down.

I have attached the diagnostics zip file to the first post. sorry

So if read SMART is not the cause, something else is waking the drives first. I already ruled out Docker containers, all plugins (safe mode), and confirmed the issue persists with poll_attributes=0. I also confirmed via inotifywait that /dev/sdg gets OPEN→ACCESS→CLOSE every ~60 seconds. What would you suggest as next step to identify what is actually issuing that initial wakeup

Since 7.2, my drives never stay spun down. They spin down successfully but emhttpd wakes them immediately via "read SMART" every ~60 seconds. Syslog pattern (repeats endlessly): May 12 13:13:02 emhttpd: spinning down /dev/sdf May 12 13:14:04 emhttpd: read SMART /dev/sdf Tested and ruled out as causes: Safe Mode (all plugins disabled) → issue persists All Docker containers stopped → issue persists poll_attributes=0 → no effect pcie_aspm=off kernel parameter → no effect ASM1166 firmware updated → no effect smartctl replaced with dummy (exit 0) → no effect The dummy test is the key finding: emhttpd does not use the smartctl binary. It issues ioctl calls directly to the block device, confirmed via kernel ftrace (kprobe on blkdev_ioctl). This is a hardcoded timer completely independent of poll_attributes. Drives with APM support (Seagate IronWolf, WD Red EFRX) are less affected. Drives without APM (WD Blue EZRZ, WD Red Plus EFPX) wake up on every ioctl. Has anyone found a workaround? boricua-diagnostics-20260512-1621.zip