Hi.I've very recently bought a ReadyNAS Ultra2 and stuffed it with 2x2TB (WD Caviar Green) disk.SW: RAIDiator 4.2.19Addons: ReadyNAS Photos II, ReadyNAS Skifta, ReadyNAS Remote and EnableRootSSHI've configured disk spindown after 60 minutes delay.When I check the log files I can see that the disks are spinning up at times where there should be no activity demanding it (PCs on LAN down, only two sleeping iPhones and a LaserJet printer in powersave). The frequency is close to 2 1/2 hours of sleep time.Sep 21 19:15:26 MyNAS noflushd[4950]: Disks spinning up after 182 minutes.Sep 21 20:38:56 MyNAS noflushd[4950]: Spinning down disks.Sep 21 22:58:58 MyNAS noflushd[4950]: Disks spinning up after 140 minutes.Sep 22 00:08:20 MyNAS noflushd[4950]: Spinning down disks.Sep 22 03:00:49 MyNAS noflushd[4950]: Disks spinning up after 172 minutes.Sep 22 04:24:15 MyNAS noflushd[4950]: Spinning down disks.Sep 22 06:42:38 MyNAS noflushd[4950]: Disks spinning up after 138 minutes.Sep 22 08:05:02 MyNAS noflushd[4950]: Spinning down disks.Sep 22 10:29:33 MyNAS noflushd[4950]: Disks spinning up after 144 minutes.Sep 22 11:39:58 MyNAS noflushd[4950]: Spinning down disks.Sep 22 14:29:44 MyNAS noflushd[4950]: Disks spinning up after 169 minutes.Sep 22 15:55:19 MyNAS noflushd[4950]: Spinning down disks.Sep 22 18:13:15 MyNAS noflushd[4950]: Disks spinning up after 137 minutes.I've forwarded a non-standard port number to the HTTPS server for external WebDAV & FrontView access.I have not been able to conclude any activity that could explain the disk spin up after browsing through the log files as far as I could understand them (nothing abnormal in auth.log except for the regular CRON[1404]: (pam_unix) session opened for user root by (uid=0) messages).Could it be a port scanner finding the port number and blasting passwords to the HTTPS port?Any ideas on how to proceed with finding the cause for the disk spinups?/f

VOILA!!!I seem to have made a breakthrough yesterday - in my research for the reason to the undesired spinups I seem to have isolated the root cause to either the ReadyNAS Remote or ReadyNAS Skifta add-ons. After purging them from my NAS and reboot (to get rid of the lingering Remote's leafp2p process with outgoing HTTPS connections) my disks are no longer spinning up.When looking into the /var/log/syslog I can now "enjoy" seeing my terabytes getting some good resting between the work shifts!Sep 23 20:26:06 MyNAS noflushd[1738]: Spinning down disks.Sep 23 20:30:25 MyNAS noflushd[1738]: Disks spinning up after 4 minutes.Sep 24 03:33:31 MyNAS noflushd[1718]: Spinning down disks.Sep 24 20:17:28 MyNAS noflushd[1718]: Disks spinning up after 1003 minutes.So, I guess reinstalling Remote or Skifta would be the next thing to do to isolate the fault to one of them (and I put some money on Remote due to its outgoing network connections)./f

Anyone with similar experiences?/f

I have an NV+ and this has been a REAL irritant for a long time. My NV+ is set to spin-down after 10 minutes, and the only time it is actually in use is daily at 11pm when I back-up one of my PCs to it. Yes, that's all it does--I have no other services running on this NAS, not even a printer or USB drive connected.But it frequently spins-up again after my 11pm backups, and virtually every dat at 205am and 0400am the drives spin-up, I don't know why. This morning again I see at 645am that the bloody thing is spun-up, then I watch as it spins up and then down and then up and then down.I submitted a trouble ticket to Tech Support about it, and they supposedly reviewed my logs and said "Normal behavior".Certainly not good for my drives to be turning them Off & On & Off & On...! :oops:

4am would probably be the daily online SMART check (not a good idea to disable this as this check is important as it often provides advance warning before disk failure). If you have SSH access you can check for cron jobs etc. and see if the times match

As far as I recon, SMART checking will not wake up spun down disks.The /frontview/bin/check_smart_errors cronjob is scheduled 4 AM every morning.However, it will detect spun down disks and abort itself if waiting for spinup takes more than 24 hours (and the next scheduling takes place).Fragments from "/frontview/bin/check_smart_errors"if [ -f /ramfs/spindown ]; then # Check for spindown mode (up to 24 times a day) before continuiing. # Avoid waking up spun-down disks. while [ $hour -lt 24 ]; do if grep -q ":1" /ramfs/spindown; then delay_smart=1 sleep 3600 # Wait an hour before trying again else unset delay_smart break fi hour=$(($hour + 1)) done [ -n "$delay_smart" ] && exit -1fiThe second from last row will call exit if all 24 loops were carried out with disks still spun down.This is from my syslog:Sep 27 23:47:44 MyNAS noflushd[1743]: Spinning down disks.Sep 29 19:36:31 MyNAS noflushd[1743]: Disks spinning up after 2628 minutes.The disks never spun up on the 28th or the morning of 29th - two 04 AM passed without any activity.However, even after removal of ReadyNAS Remote my disks seem to spin up with no good reason from time to time.My hunting has to continue I believe... :-)/f

Why are my NAS's disks spinning up after ~2 1/2 hrs sleep?

20 Replies

Replies have been turned off for this discussion

flyvert
Aspirant
Oct 02, 2011
Someone wrote that "low end SATA" devices (such as my WD Green Caviar 2TB disk compared to SAS, et.c) is not built for 24x7 spinning and continous motion will decrease their life time.

But spinning down and up like a jojo isn't that good either I guess...
... so if I decide to let my disks rest when idle for a while I sure like to know why they are spinning up if there is no computer, squeezebox, iPhone, pad, etc. on the network requiring access to it...

During my first few weeks with ReadyNAS I seem to have stumbled on like 4-5 bugs so far... (search for my posts) this one being one of the more annoying ones...
... I wonder if the disturbed sleep is a bug in RAIDator "firmware", the Linux kernel, ReadyNAS hardware or due to some external effects, e.g. port scanner findng my open ports, etc.

/f

maxblack

Aspirant

Oct 18, 2011

flyvert wrote:
From what I've read about noflushd, the daemon (backgrund process in Unix) spins down disks not being read from for a while.

flyvert wrote:
From what I've read about noflushd, the daemon (backgrund process in Unix) spins down disks not being read from for a while.

Hey flyvert, as I continue to try to figure-out my own problems wrt spin-up, and spinning-up after 0 minutes, I came across a confirmation of your noflushd theory here (and no I haven't been brave enough to try it yet):

viewtopic.php?p=163658

Skywalker wrote:You can run "noflushd -d -v -n 1" to run in the forground, showing all debug information, and it will spin the disks down after 1 minute of inactivity.

Another point of interest, I found a discussion here regarding drives that don't like the way the ReadyNAS deals with them, so a patch was tried (and abandoned I think) to work-around the issue:

Skywalker wrote:
There were actually two problems that could affect [unexpected spinups/downs].
First, which the first patch should have addressed, is that the disks were normally spinning down in the wrong order; so the parity drive was being spun down before the other drives, so when the other drives were synced before spindown, the write woke up the parity drive. There were many times when it would still spin down though, so this could be a random spindown failure on the parity drive.
Second is a bit more complicated. We found that the OS tells a disk device to flush its write cache when opening or closing, if that device isn't currently used by anything else. Since X-RAID is done at a lower level then even the kernel, the kernel doesn't know it's in use, it sends the flush cache command to the disk immediately after we send the standby command. Now the interesting part here is that most disks that we have will ignore that cache flush command if 1) the disk in in standby mode, or 2) there is nothing in the cache to flush. But others will bring the disk out of standby mode and flush the cache. You can even have two disks with the same model but different firmware that handle this differently. Anyway, the fix to stop that from happening was to just open the partity drive during the spindown daemon's initial scan, and never close it (don't worry, this is harmless). This "tricks" the kernel into not flushing the cache immediately after spinning it down.

Skywalker wrote:
There were actually two problems that could affect [unexpected spinups/downs]. First, which the first patch should have addressed, is that the disks were normally spinning down in the wrong order; so the parity drive was being spun down before the other drives, so when the other drives were synced before spindown, the write woke up the parity drive. There were many times when it would still spin down though, so this could be a random spindown failure on the parity drive. Second is a bit more complicated. We found that the OS tells a disk device to flush its write cache when opening or closing, if that device isn't currently used by anything else. Since X-RAID is done at a lower level then even the kernel, the kernel doesn't know it's in use, it sends the flush cache command to the disk immediately after we send the standby command. Now the interesting part here is that most disks that we have will ignore that cache flush command if 1) the disk in in standby mode, or 2) there is nothing in the cache to flush. But others will bring the disk out of standby mode and flush the cache. You can even have two disks with the same model but different firmware that handle this differently. Anyway, the fix to stop that from happening was to just open the partity drive during the spindown daemon's initial scan, and never close it (don't worry, this is harmless). This "tricks" the kernel into not flushing the cache immediately after spinning it down.

BTW the patch referenced in that thread doesn't work with at least my version of RAIDiator. For my part, I have found a new revision of firmware for my Seagate drives, and I think before I muck with any cron jobs in my ReadyNAS, I will update the firmware first and see if that fixes my problems. For example, while I have the same check_smart_errors command as you posted about earlier in this thread, including the bit about "check first if spundown i.e. don't spin-up to do this" and on my NAS it's not working.

flyvert
Aspirant
Oct 26, 2011
I'm still gathering statistics to get a better view of the problem.

This is how October looks, so far

Oct 1 01:00:09 51 minutes.
Oct 1 20:00:05 576 minutes.
Oct 2 01:16:21 53 minutes.
Oct 2 11:20:13 542 minutes.
Oct 2 15:39:04 190 minutes.
Oct 3 00:08:08 9 minutes.
Oct 3 02:00:09 51 minutes.
Oct 3 04:00:08 53 minutes.
Oct 3 08:24:55 143 minutes.
Oct 3 18:16:11 521 minutes.
Oct 3 19:28:18 10 minutes.
Oct 4 18:25:57 1168 minutes.
Oct 5 02:00:10 76 minutes.
Oct 5 04:00:10 50 minutes.
Oct 5 09:07:56 186 minutes.
Oct 5 17:33:55 443 minutes.
Oct 5 18:59:22 23 minutes.
Oct 6 02:05:13 63 minutes.
Oct 6 04:00:09 49 minutes.
Oct 6 06:29:53 28 minutes.
Oct 6 09:06:18 85 minutes.
Oct 6 18:34:16 503 minutes.
Oct 6 21:53:32 14 minutes.
Oct 7 00:02:36 0 minutes.
Oct 7 02:05:12 61 minutes.
Oct 7 04:00:13 54 minutes.
Oct 7 09:19:21 258 minutes.
Oct 7 16:32:25 362 minutes.
Oct 8 02:05:13 37 minutes.
Oct 8 08:15:02 309 minutes.
Oct 8 16:39:39 373 minutes.
Oct 8 22:05:51 0 minutes.
Oct 9 04:00:08 293 minutes.
Oct 9 21:07:23 905 minutes.
Oct 10 18:52:06 1205 minutes.
Oct 11 07:54:28 173 minutes.
Oct 11 16:37:31 459 minutes.
Oct 11 20:22:50 158 minutes.
Oct 12 02:00:21 27 minutes.
Oct 12 04:00:11 53 minutes.
Oct 12 07:54:48 113 minutes.
Oct 12 22:12:07 794 minutes.
Oct 13 02:29:08 130 minutes.
Oct 13 18:41:48 908 minutes.
Oct 13 19:59:44 10 minutes.
Oct 14 04:00:12 5 minutes.
Oct 14 06:20:29 18 minutes.
Oct 14 17:19:21 502 minutes.
Oct 15 02:00:22 20 minutes.
Oct 15 04:00:08 53 minutes.
Oct 15 07:55:27 113 minutes.
Oct 15 09:44:38 46 minutes.
Oct 16 08:32:10 1256 minutes.
Oct 16 16:56:34 370 minutes.
Oct 17 02:00:23 35 minutes.
Oct 17 04:00:12 53 minutes.
Oct 17 07:55:53 114 minutes.
Oct 17 18:41:21 562 minutes.
Oct 18 01:53:08 13 minutes.
Oct 18 04:00:09 54 minutes.
Oct 18 07:56:11 114 minutes.
Oct 18 15:22:01 375 minutes.
Oct 18 19:50:19 206 minutes.
Oct 19 03:08:10 2 minutes.
Oct 19 07:56:37 175 minutes.
Oct 22 02:05:10 3897 minutes.
Oct 22 09:35:49 387 minutes.
Oct 23 20:45:33 2046 minutes.
Oct 25 03:00:07 1749 minutes.
Oct 26 19:24:20 2360 minutes.

The 04 and 02 spinups are defintely worth focusin on...

To be continued...

/f
flyvert
Aspirant
Oct 26, 2011
Yup, the 02 and 04 spinups sure looks tied to the two scripts mentioned earlier.

Here's my NAS's "red eye" spinups for the last month joined with the cronlog contents just prior spinup

Sep 26 04:00:01 MyNAS /USR/SBIN/CRON[7774]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Sep 26 04:00:09 MyNAS noflushd[1718]: Disks spinning up after 54 minutes.

Sep 30 04:00:01 MyNAS /USR/SBIN/CRON[23172]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Sep 30 04:00:08 MyNAS noflushd[1743]: Disks spinning up after 53 minutes.

Oct 3 04:00:01 MyNAS /USR/SBIN/CRON[30599]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 3 04:00:08 MyNAS noflushd[1743]: Disks spinning up after 53 minutes.

Oct 5 04:00:01 MyNAS /USR/SBIN/CRON[5512]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 5 04:00:10 MyNAS noflushd[1743]: Disks spinning up after 50 minutes.

Oct 6 02:05:01 MyNAS /USR/SBIN/CRON[4041]: (root) CMD ( nice -n 19 /frontview/bin/check_nonredundant_raid &> /dev/null)
Oct 6 02:05:13 MyNAS noflushd[1743]: Disks spinning up after 63 minutes.

Oct 6 04:00:01 MyNAS /USR/SBIN/CRON[6716]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 6 04:00:09 MyNAS noflushd[1743]: Disks spinning up after 49 minutes.

Oct 7 02:05:01 MyNAS /USR/SBIN/CRON[9783]: (root) CMD ( nice -n 19 /frontview/bin/check_nonredundant_raid &> /dev/null)
Oct 7 02:05:12 MyNAS noflushd[1743]: Disks spinning up after 61 minutes.

Oct 7 04:00:01 MyNAS /USR/SBIN/CRON[12386]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 7 04:00:13 MyNAS noflushd[1743]: Disks spinning up after 54 minutes.

Oct 8 02:05:01 MyNAS /USR/SBIN/CRON[10515]: (root) CMD ( nice -n 19 /frontview/bin/check_nonredundant_raid &> /dev/null)
Oct 8 02:05:13 MyNAS noflushd[1743]: Disks spinning up after 37 minutes.

Oct 9 04:00:01 MyNAS /USR/SBIN/CRON[14234]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 9 04:00:08 MyNAS noflushd[1743]: Disks spinning up after 293 minutes.

Oct 12 04:00:01 MyNAS /USR/SBIN/CRON[21719]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 12 04:00:11 MyNAS noflushd[1735]: Disks spinning up after 53 minutes.

Oct 13 02:23:01 MyNAS /USR/SBIN/CRON[20665]: (root) CMD ( /usr/bin/empty_exim &>/dev/null)
Oct 13 02:29:08 MyNAS noflushd[1735]: Disks spinning up after 130 minutes.

Oct 14 04:00:01 MyNAS /USR/SBIN/CRON[23969]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 14 04:00:12 MyNAS noflushd[1735]: Disks spinning up after 5 minutes.

Oct 15 04:00:01 MyNAS /USR/SBIN/CRON[22864]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 15 04:00:08 MyNAS noflushd[1735]: Disks spinning up after 53 minutes.

Oct 17 04:00:01 MyNAS /USR/SBIN/CRON[24626]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 17 04:00:12 MyNAS noflushd[1735]: Disks spinning up after 53 minutes.

Oct 18 04:00:01 MyNAS /USR/SBIN/CRON[25242]: (root) CMD ( nice -n 19 /frontview/bin/check_smart_errors &> /dev/null)
Oct 18 04:00:09 MyNAS noflushd[1735]: Disks spinning up after 54 minutes.

Oct 22 02:05:01 MyNAS /USR/SBIN/CRON[26428]: (root) CMD ( nice -n 19 /frontview/bin/check_nonredundant_raid &> /dev/null)
Oct 22 02:05:10 MyNAS noflushd[1735]: Disks spinning up after 3897 minutes.

However, it has been sleeping a lot lately...
Oct 19 07:56:37 MyNAS noflushd[1735]: Disks spinning up after 175 minutes.
Oct 22 02:05:10 MyNAS noflushd[1735]: Disks spinning up after 3897 minutes.
Oct 22 09:35:49 MyNAS noflushd[1735]: Disks spinning up after 387 minutes.
Oct 23 20:45:33 MyNAS noflushd[1735]: Disks spinning up after 2046 minutes.
Oct 25 03:00:07 MyNAS noflushd[1735]: Disks spinning up after 1749 minutes.
Oct 26 19:24:20 MyNAS noflushd[1735]: Disks spinning up after 2360 minutes.

I just stopped the avahi (Bonjour?) service it was puking a lot of
avahi-daemon[2600]: Received response with invalid source port 32788 on interface 'eth1.0'
probably due to my squeezebox sending something it couldn't interpret every 30th second.
I wonder if avahi was left on since I played with AFP (now disabled).

I also decided to deactivate TiVo since it seemed to do some stuff at about 02:00 every morning (and I've got no use of it right now).

The hunt continues...

/f
maxblack
Aspirant
Oct 27, 2011
Flyvert I guess you & I are the only users on Planet Earth to care about this subject! I have an NV+ which no doubt is different from your Ultra, but here is some of what I found about spinups:

1. cron.daily activates at 0625, then .weekly and .monthly are at 0647 and 0652, doesn't appear ALWAYS to spin me up tho?

2. check_nonredundant_raid in cron.d starts at 0205 every day, spinning-up disks to do so, without exception

3. check_smart_errors in cron.d starts at 0400 every day, and spins-up despite the "Avoid waking spun-down disks" code therein

Apparently your Ultra doesn't start at 0205 like mine does; just wanted to let you know that I've been trying to methodically look at crontab, cron.d, cron.daily .weekly .monthly, and all the commands therein to try to get my head around what the NAS is doing.

I have every service turned-off in my NV+, but it seems sometimes when I start a PC on my network it wakes my NV+. I don't even use the NV+ as Master Browser so I'm not sure what that's about... :o
mrichmon
Aspirant
Nov 05, 2011
Just noticed this spin-down with a spin-up occurring immediately after the spin down while sitting beside my NAS for the evening.

Since I've just rebuild my array after loosing 2 hard drives in a row I'm very interested in this issue. Is it possible that automount with nfs on the server side might be causing the spin down with immediate spin-up?

maxblack

Aspirant

Nov 05, 2011

In my quest to find the cause for my own "spin-ups after 0 minutes", it seems a function (weakness) of noflushd that is responsible for the spin-downs. From a man page I found:

Journaling filesystems like ext3, or reiserfs bypass the kernel’s
delayed write mechanisms and write straight to disk. Therefore
noflushd is unable to postpone writing of journaling data. As a
result, expect lousy spindown behaviour when working off
ext3/reiserfs/... partitions.

There is a newer version of noflushd that is available vs. that which is used in the ReadyNAS, but I dunno if it will help or not. In the meantime those of us who worry about this issue have been left to dangle by Netgear, and AFAICT the only alternative is to let 'em spin 24/7.

flyvert
Aspirant
Nov 05, 2011
Since I'm new to this I'm unsure if you could temporarily replace the old noflushd?
If you could find a newer version from a matching platform, renaming the old to .org and inject the new should not cause any unrepairable damage?
Worst thing would probably be a kernel panic requiring you to single user mode boot* the box and restore the original version?

*) serial/console cable + keyboard required???

/f
maxblack
Aspirant
Nov 05, 2011
I'm not sure how to do it myself, but here's the sparc version for debian:

http://packages.debian.org/squeeze/spar ... d/download

* noflushd 2.8 (25. July 2010)

- Add support for SGIO interface in current Linux kernels.
- Avoid spurious spinups from udev-trigger re-read of partition data on
block devices.

Dunno what this means re: udev-trigger or how it might affect us if at all! Current version is 2.7.5 from 2005. :o
Lithium-Admin
Novice
Nov 29, 2011
Hi,

Any news on replacing noflushd with the newer version? My Duo spins up immediately after spinning down...

Greetings

Forum Discussion

Why are my NAS's disks spinning up after ~2 1/2 hrs sleep?

20 Replies

Related Content

RBR50 Firmware Update page just spins

Nighhawk M6 WLAN goes to sleep

Ready NAS 102 app problem

Netgear EX6420 AC1900 in sleep

orbi modalità sleep

NETGEAR Academy

ProSupport for Business