iDwucWEDSaE.U3jetfc2uz

TL;DR: Unraid's behavior with enterprise-grade disk is a little odd, but I managed to make those drives to sleep, and slightly patched the GUI to display the real state of disks. It turned out that running hdparm -S wasn't enough to COMPLETELY prevent disks wakes-up, but reduce it to once every 4-5 days. Which is satisfying enough to keep this configuration. In the end, here are the mandatory configuration items : Set Default spin down delay to NEVER. It is absolutely crucial to set the default to never ; otherwise Unraid keeps waking the disk every 9 hours (even if the default is set to X minutes, and specific disks are setup to never be spun down). For disks that aren't Enterprise-grade HDD, set a specific spin down delay to whatever. APM must be disabled (hdparm -B 255 /dev/sdX) Smart offline data collection must be disabled as well (smartctl -o off /dev/sdX) EPC doesn't seem to have any impact The only caveat of this setup is that from the GUI, disks are always marked as "Active" ; even if the disks are spun down. I think it is related to the fact that the default spin down delay in Unraid changes the global behavior of the disk monitoring. Idealy, to fix this issue, we would have to gain control over what writes into /var/local/emhttp/disks.ini, but this file is being overwritten every second or so by a thread of emhttpd. What I did is setup a patch for /usr/local/emhttp/plugins/dynamix/nchan/update_2 ; checking for the state of Toshiba enterprise-grade disks. For those interested, here is the patch : --- /usr/local/emhttp/plugins/dynamix/nchan/update_2 2026-02-20 16:46:42.299061313 +0100 +++ /usr/local/emhttp/plugins/dynamix/nchan/update_2.patched 2026-02-20 16:48:55.535689177 +0100 @@ -169,6 +169,9 @@ function device_status(&$disk, &$error, &$warning) { global $var; + if (str_contains(_var($disk,'id'), 'TOSHIBA_MG') && str_contains(exec('hdparm -C /dev/' . var($disk,'device')), 'drive state is: standby')) { + $disk['color'] = 'green-blink'; + } if (var($disk,'type')!='Extra' && var($var,'fsState')=='Stopped') { $color = 'green'; $text = 'off-line'; } else switch (var($disk,'color')) {To apply it immediately, run patch /usr/local/emhttp/plugins/dynamix/nchan/update_2 < /boot/custom/update_2.patched and restart nginx (/etc/rc.d/rc.nginx restart). To make it permanent, modify your /boot/config/go file to patch on every boot.

Modifying the global "Default spin down delay" configuration (or changing the specific configuration disk by disk) to "never", and issuing the following commands "solved" this issue : hdparm -S 180 /dev/sdb hdparm -S 180 /dev/sdc When I monitor the disks with hdparm -C, drive state keeps in standby mode. I'll try to re-enable APM, EPC and Smart data offline collection to see if it changes anything, but now, when my disks go to sleep, they do not wake up as they did before. The last thing I have to fix is the webGUI of unraid does not detect properly that disks are spun down

My parity disk is /dev/sdb. As you can see from the syslog or the short extract of log in my first post, /dev/sdb is the only disk to wake up on Jan 29 05:23:37. But there are more examples of this behavior in the syslog file. The thing is, I think I did everything I could about power-management on those drives. I enabled / disabled APM and EPC, or tried different values for APM, but nothing changed.

yes, one of them is parity, and the parity disk can be woken up alone (the second toshiba being woken up at a later time) As only Toshiba disks are woken up, and not the WD, I'm leaning towards a "disk" issue, rather than a "user access" issue. Both disks (WD and Toshiba) contains data of user shares, but only Toshiba wake up every X hours. Besides, the ethernet cable is unplugged, so that nothing can reach the NAS from the network. I could stop others services like SMB to be 100% sure though ... I might try it in the upcoming days. I would love too, but the Toshiba has more data in it than the WD total capacity. It would be a lot of work, and to be frank, is not my main hypothesis as to why disks are woken up. But I'll keep this test in my mind for later. The zip file is attached to this post. By the way, thank you so much for digging into my issue, really appreciated. diagnostics-20260130-2131.zip

Ooh, I get the confusion. i'm sorry, didn't make myself clear on the first post. What I meant with "every 9h45" is "every 9 hours and 45 minutes" (as seen in the logs) ; which is more than twice a day ! If we take for example /dev/sdb : Jan 29 05:23:37 ugreen emhttpd: read SMART /dev/sdb Jan 29 05:38:38 ugreen emhttpd: spinning down /dev/sdb ... Jan 29 15:08:05 ugreen emhttpd: read SMART /dev/sdb Jan 29 15:23:06 ugreen emhttpd: spinning down /dev/sdb it wakes up at 5:23, goes to sleep 15 mins later, and then gets woken up again at 15:08... which is 9 hours and 45 minutes later. I rebooted my system into safemode, so it should be safe to assume no plugin or app are executing, right ? (I'm still new to unraid) What really bugs me, is that the problem occurs only with my Toshiba drives... My WD HDD is sleeping as expected

No, all my HDD drives are formatted using XFS. My cache SSD is formatted with btrfs however

TL;DR: Every 9h45 (that's precise !), my toshiba drives wake up even when there's no user activity. All other drives are fine and behave as they should. The symptom/problem: When not in use, my syslog file looks like this : Jan 29 03:55:40 ugreen emhttpd: read SMART /dev/sdc Jan 29 04:10:41 ugreen emhttpd: spinning down /dev/sdc Jan 29 05:23:37 ugreen emhttpd: read SMART /dev/sdb Jan 29 05:38:38 ugreen emhttpd: spinning down /dev/sdb Jan 29 13:40:44 ugreen emhttpd: read SMART /dev/sdc Jan 29 13:55:45 ugreen emhttpd: spinning down /dev/sdc Jan 29 15:08:05 ugreen emhttpd: read SMART /dev/sdb Jan 29 15:23:06 ugreen emhttpd: spinning down /dev/sdb A word about my setup: - The system is hosted by a Ugreen DXP4800 (4 HDD / 2 SSD). I have 3 drives online and active in the array (one parity, two data drives), as well as one nvme SSD for cache and a few user shares (including Appdata and System). - From these 3 data drives, two of them are Toshiba MG08ACA16TE (NAS/enterprise grade HDD), and the last one is a Western Digital. I also have another HDD in the 4th slot, but it's not included in the array and not being used. - Spin down delay is set to 15 mins - Most of my shares are on data HDDs formatted in XFS, but all my docker activity or things Idonotcareabout are on the cache SSD (formatted with btrfs). Every 9h45 (more than twice a day), both Toshiba disks wake up for an unknown reason. As the spin down default - no swap on the system My first reflex was to look for read or write accesses to my disks, with the "File Activity" plugin, but it showed nothing. I then quickly moved on to other techniques, including the usage of iotop and pspy, but nothing stood out. Web searches on this forum and reddit returned many results, and every time, there was a user-process that was accessing the disks for some reason. So I though that was my problem too. What i've done/tried so far while in safemode: - stopped docker - stopped Qemu - disabled automatic mover - disabled scheduled parity check - disabled scheduled trim - stopped crond service (should be enough for scheduled tasks i guess) - unplugged ethernet cable The problem is still present after all these steps, and I couldn't identify any read or write access to my toshiba disks. I also tried different things, without success: - changed ASPM mode - disabled offline data collection status (smartctl -o off /dev/sdx) - changed APM value to 1, 127, 255 (disabled) - disabled / enabled EPC (with openSeaChest) I'm starting to run out of ideas, is there anything else that I can try to troubleshoot this problem?