Zentachi Posted February 28, 2021 Share Posted February 28, 2021 (edited) 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, 2021 by Zentachi Solved Quote Link to comment
kaiguy Posted March 2, 2021 Share Posted March 2, 2021 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. Quote Link to comment
Redskyer Posted March 2, 2021 Share Posted March 2, 2021 (edited) 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, 2021 by Redskyer more detailed description and attached diagnostics Quote Link to comment
xruchai Posted March 2, 2021 Share Posted March 2, 2021 (edited) 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, 2021 by xruchai Quote Link to comment
ivayloivanov82 Posted March 2, 2021 Share Posted March 2, 2021 (edited) 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, 2021 by ivayloivanov82 Quote Link to comment
AnimusAstralis Posted March 2, 2021 Share Posted March 2, 2021 (edited) 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, 2021 by AnimusAstralis Quote Link to comment
Andiroo2 Posted March 2, 2021 Share Posted March 2, 2021 (edited) 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, 2021 by Andiroo2 Problem solved! Quote Link to comment
ivayloivanov82 Posted March 2, 2021 Share Posted March 2, 2021 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. Quote Link to comment
Zentachi Posted March 2, 2021 Author Share Posted March 2, 2021 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. Quote Link to comment
Redskyer Posted March 3, 2021 Share Posted March 3, 2021 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 Quote Link to comment
SimonF Posted March 3, 2021 Share Posted March 3, 2021 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. Quote Link to comment
Redskyer Posted March 3, 2021 Share Posted March 3, 2021 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. Quote Link to comment
SimonF Posted March 3, 2021 Share Posted March 3, 2021 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. Quote Link to comment
Redskyer Posted March 3, 2021 Share Posted March 3, 2021 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. Quote Link to comment
Zentachi Posted March 3, 2021 Author Share Posted March 3, 2021 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! Quote Link to comment
Carpe_Diem Posted March 3, 2021 Share Posted March 3, 2021 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. 1 Quote Link to comment
SimonF Posted March 3, 2021 Share Posted March 3, 2021 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. Quote Link to comment
Zentachi Posted March 3, 2021 Author Share Posted March 3, 2021 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". Quote Link to comment
Carpe_Diem Posted March 3, 2021 Share Posted March 3, 2021 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. Quote Link to comment
Nexius2 Posted March 3, 2021 Share Posted March 3, 2021 same issue for me. manual spin down ok, but not in automatic Quote Link to comment
Andiroo2 Posted March 3, 2021 Share Posted March 3, 2021 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 Quote Link to comment
Emil Hansen Posted March 5, 2021 Share Posted March 5, 2021 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 2 Quote Link to comment
jonp Posted March 8, 2021 Share Posted March 8, 2021 Just an FYI guys, we are aware of this issue and plan to have a fix in for 6.9.1. 3 1 Quote Link to comment
Redskyer Posted March 9, 2021 Share Posted March 9, 2021 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. 2 Quote Link to comment
Gonzo-the-great Posted March 9, 2021 Share Posted March 9, 2021 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. 1 Quote Link to comment
Recommended Posts
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.