February 28, 20215 yr Hi all, I have built my first unraid for a month now more or less and I have a problem that cannot seem to resolve. My setup is 1x8 TB WD purple, 2x8 TB WB purple, 3 cache pools ( 1x512 GB NVME, 1x512 GB NVME and 1x1 TB SSD). I am using Version: 6.9.0-rc2. My issue is that my array disks do not spin down automatically! When I click the spin down they do without any issues and remain like that until I spin them up or start using the shares. There are no active streams, no file activity and the open files plugin shows only connections to the cache drives and nothing to the data disks. I have played with the delay both in global settings and per disk, but nothing. Any insight of what should I check? As I mentioned when I manually click to spin them down it works and they remain like that. The auto spin down delay isn't working. Many thanks Edited March 11, 20215 yr by Zentachi Solved
March 2, 20215 yr Just upgraded to 6.9.0 and I'm noticing this as well. All disks are set to use the default delay, and the default delay is set for 30 minutes. Disks do not spin down.
March 2, 20215 yr I got the same error. I noticed this error with 6.9.0 RC2. Before that Version everything was working like expected. In the Array Monitor the disks were shown as spin down, but I can hear the disks running. Edit: My problem is mayby a bit different as the described one above. I'm using a small server with an external 4-bay USB 3.0 storage device from Fantec. It is connected by USB 3.0 and I have 4 WD Red in that case. Additionally 2 WD Red + 1 SSD in the server case connected via S-ATA. Since UNRaid 6.9.0 RC2 the disks in the external case were not detected corretly. If the drives spin-up because of an access, UNRaid doesn't notice that. I got no SMART values. And because of that they won't spin-down correctly, because UNRaid doesn't know that they're up. But if I spin them up manually everything is working fine. They spin down after 30 min and I get the values. Every drive on the screenshot should be green, because they're running. I hope, that someony has an idea what I can do. media-server-diagnostics-20210302-1301.zip Edited March 2, 20215 yr by Redskyer more detailed description and attached diagnostics
March 2, 20215 yr With me unfortunately the same, after the update to 6.9 Final the HDD's (sata) no longer go into standby, no spin down. Since in Germany the electricity prices are quite high this is a big problem for me :(. Edited March 2, 20215 yr by xruchai
March 2, 20215 yr Same here. I can provided statistics upon request. It has been the same before where i tried 6.9 RC2. Then i reverted back to wait for the stable 6.9, but today the same issue, disks not spinning down. thebrain-diagnostics-20210302-1615.zip Edited March 2, 20215 yr by ivayloivanov82
March 2, 20215 yr Got this problem as well. I've updated from previous stable version. Noticed it after one of my old HDDs got hot. Edit: 1) spun down whole array; 2) spun up single HDD; 3) stopped Grafana-related docker containers (grafana, influxdb, nut-influxdb-exporter, telegraf, varken) Automatic spin down works again. Yet it worked fine on previous stable version, so I think this should be considered as a bug. Edited March 2, 20215 yr by AnimusAstralis
March 2, 20215 yr Same here...was on 6.9 RC2 with no spin down, and now on 6.9 stable I see the same...disks spin up immediately after manually spinning them down too. EDIT: I found the culprit: in Telegraf's config file (telegraf.conf) I had [inputs.hddtemp] enabled. Once I disabled this, my array stayed spun down like a good set of drives should. Edited March 2, 20215 yr by Andiroo2 Problem solved!
March 2, 20215 yr I tried all of the above and nothing worked. Then I stopped HDDTemp and that fixed it. I started all Grafana related containers again without the disks to wake from their slumber.
March 2, 20215 yr Author Thanks everyone for your input. It seems like a bug indeed. In my case as I mentioned it doesn't matter if I have docker containers running or not. Disks will not spin down automatically, however once I manually click the spin down button they will remain like that until they are accessed.
March 3, 20215 yr I'm back on 6.9.0 RC1, the last working build for me. I found a small difference in the log between 6.9.0 RC1 and 6.9.0. If I access one of these external drives than appears the following message in the log file: "Mar 3 08:15:29 Media-Server emhttpd: read SMART /dev/sdc" That doesn't happen in the release version and that's the reason why UNRaid isn't able to spin-down the drives, because UNRaid doesn't notice that the access happens and the drive spun-up. I attached a new diagnostic file from RC1. media-server-diagnostics-20210303-0816.zip
March 3, 20215 yr Community Expert 17 minutes ago, Redskyer said: read SMART /dev/sdc That message is put out when Unraid is getting temps. There is likely to be some other process that is reading the disks also to keep them spinning. The new spin down function was introduced in 6.9.0-rc1.
March 3, 20215 yr 3 minutes ago, SimonF said: That message is put out when Unraid is getting temps. There is likely to be some other process that is reading the disks also to keep them spinning. The new spin down function was introduced in 6.9.0-rc1. Not this time. I accessed that drive and thatswhy it spun up, but that message doesn't appear in RC2 or the release version on an access.
March 3, 20215 yr Community Expert If I spin up a drive via accessing say from a Windows PC accessing a disk share I get that message when unraid detects the spinup. If you have something that is running using smartctl -n standby then now it will read the disk as it is no longer spun down. But while it was spun down it wouldnt process the smartctl. There are issues with the way unraid is dealing with IO usage and there are bug reports for that already. Others have found issues if using Telegraf or Autofan etc that is keeping the disk spinning that didnt happen before.
March 3, 20215 yr 14 minutes ago, SimonF said: If I spin up a drive via accessing say from a Windows PC accessing a disk share I get that message when unraid detects the spinup. That happens in my case too, but just until RC1. Since RC2 UNRaid doesn't detect the spin-up and I don't know why. Quote Others have found issues if using Telegraf or Autofan etc that is keeping the disk spinning that didnt happen before. I don't use any of them.
March 3, 20215 yr Author 1 hour ago, SimonF said: If I spin up a drive via accessing say from a Windows PC accessing a disk share I get that message when unraid detects the spinup. If you have something that is running using smartctl -n standby then now it will read the disk as it is no longer spun down. But while it was spun down it wouldnt process the smartctl. There are issues with the way unraid is dealing with IO usage and there are bug reports for that already. Others have found issues if using Telegraf or Autofan etc that is keeping the disk spinning that didnt happen before. Your post helped me find the culprit! It was "Autofan". Even though I could manually spin down the disks and they would remain down, it seems "Autofan" wasn't allowing this to happen automatically. I disabled "Autofan" and now the delay spin down works!
March 3, 20215 yr Just to note: Autofan is not always the culprit. I have exactly this same behavior, and even after rebooting in safe mode (all plugins disabled), drives do not spin down. I also get 341B/s read metrics on all drives simultaneously, whick Unraid seems to register even when the drives are manually spinned down. I just reverted to 6.8.3 and this feature started working perfectly fine again.
March 3, 20215 yr Community Expert 2 minutes ago, Zentachi said: delay spin down works! Good news, The issue IO count is increasing and the spin down process sees this as usage and doesn't now spin down. 3 minutes ago, Carpe_Diem said: Autofan is not always the culprit Agreed that is not the only cause but processes using smartctl seem to be the main reason at present, but there may be other reasons.
March 3, 20215 yr Author 29 minutes ago, Carpe_Diem said: Autofan is not always the culprit. 21 minutes ago, SimonF said: Agreed that is not the only cause but processes using smartctl seem to be the main reason at present, but there may be other reasons. Indeed, it worked in my case but definitely there might be other reasons for not spinning down. Nevertheless, "Autofan" and processes using smartctl should be checked if someone has a similar problem. I would never have thought that my issue was caused by "Autofan".
March 3, 20215 yr 35 minutes ago, SimonF said: Agreed that is not the only cause but processes using smartctl seem to be the main reason at present, but there may be other reasons. Since I tried performing a safe reboot (that means no plugins, no docker) and the issue still persist, if smartctl is to be blamed, then it must be an OS smartctl process (perhaps the temperature probe?). In any case, UnRaid should ignore those smartctl queries when counting for time without IO usage to spin down. The fact that the drives are not immediately awaken after spin down means that smartctl (or whatever process it is) does not really "keeps awake" the drives, but Unraid just fails to ignore those IO and keep counting time.
March 3, 20215 yr For me it's every hour. A SMART query fires and the drives spin up. Mar 3 07:06:51 Tower emhttpd: spinning down /dev/sdl Mar 3 07:20:01 Tower emhttpd: spinning down /dev/sdk Mar 3 07:20:01 Tower emhttpd: spinning down /dev/sdh Mar 3 07:23:05 Tower emhttpd: spinning down /dev/sdj Mar 3 07:32:17 Tower emhttpd: read SMART /dev/sdk Mar 3 07:32:27 Tower emhttpd: read SMART /dev/sdl Mar 3 07:36:38 Tower emhttpd: read SMART /dev/sdh Mar 3 07:37:00 Tower emhttpd: read SMART /dev/sdj Mar 3 07:48:59 Tower emhttpd: spinning down /dev/sdl Mar 3 07:51:40 Tower emhttpd: spinning down /dev/sdh Mar 3 07:52:02 Tower emhttpd: spinning down /dev/sdj Mar 3 07:58:33 Tower emhttpd: spinning down /dev/sdk Mar 3 08:31:20 Tower emhttpd: read SMART /dev/sdk Mar 3 08:46:22 Tower emhttpd: spinning down /dev/sdk Mar 3 08:48:31 Tower emhttpd: read SMART /dev/sdj Mar 3 08:48:43 Tower emhttpd: read SMART /dev/sdk Mar 3 08:48:56 Tower emhttpd: read SMART /dev/sdh Mar 3 09:04:03 Tower emhttpd: spinning down /dev/sdh Mar 3 09:04:16 Tower emhttpd: spinning down /dev/sdj Mar 3 09:06:16 Tower emhttpd: read SMART /dev/sdj Mar 3 09:10:36 Tower emhttpd: read SMART /dev/sdh Mar 3 09:21:19 Tower emhttpd: spinning down /dev/sdj Mar 3 09:26:00 Tower emhttpd: spinning down /dev/sdk Mar 3 09:30:29 Tower emhttpd: spinning down /dev/sdh Mar 3 09:32:28 Tower emhttpd: read SMART /dev/sdh Mar 3 09:53:16 Tower emhttpd: spinning down /dev/sdh Mar 3 10:00:11 Tower emhttpd: read SMART /dev/sdk Mar 3 10:02:57 Tower emhttpd: read SMART /dev/sdj Mar 3 10:02:59 Tower emhttpd: read SMART /dev/sdl Mar 3 10:04:35 Tower emhttpd: read SMART /dev/sdh Mar 3 10:19:39 Tower emhttpd: spinning down /dev/sdj Mar 3 10:34:30 Tower emhttpd: read SMART /dev/sdj
March 5, 20215 yr Just to chip in, I have the same experience - when spun up the disk will not spin down again. I have both the telegram-influxdb-grafana and autofan setup. I tried disabling the three dockers (telegram-influxdb-grafana). Same issue. Then i disable autofan, and the disk-spun down as the should after 15 minutes. Then i tried to start the 3 dockers again, and the problem was back. As has been pointed out, I also have the SMART readings when the disk is not spinning down. I guess this is an OS error, since the problem was not present on 6.8.3, but when I upgrade to 6.9.0rc2 and 6.9.0 and the problem was present on both of the 6.9 versions. tower-diagnostics-20210305-1019.zip
March 9, 20215 yr 11 hours ago, jonp said: Just an FYI guys, we are aware of this issue and plan to have a fix in for 6.9.1. Thank you very much! It works pertfectly! Problem solved for me.
March 9, 20215 yr 18 hours ago, jonp said: Just an FYI guys, we are aware of this issue and plan to have a fix in for 6.9.1. Yup, also worked without configuration changes for me as well.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.