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

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 -1
fi

The 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

flyvert wrote:
As far as I recon, SMART checking will not wake up spun down disks.

Well, it certainly does for mine. Might miss a day or two here or there but when I look at my logs I see 205a and 400a spinups.

I've seen 4AM spinups too, but it doesn't happen every morning.
My experience with ReadyNAS is still on its first month, I guess time will tell...

I'm planning to plant a cronjob that emails me the past weeks spindown stats every Monday or so.

/f

Honestly, the spin-ups that fry my bacon are the "Disks spinning up after 0 minutes" which I seem to get several of every day. So the disks spin-down, and then spin right back up again. Not good for them!

If you're not seeing any of these then consider yourself blessed... :)

From what I've read about noflushd, the daemon (backgrund process in Unix) spins down disks not being read from for a while.
When spun down, writes are cached/delayed until a read request is received, then the disk is spun up and cached writes are flushed, etc. and monitoring for inactivity starts over again.

If I have understood it correct, it is not a stray write that spins up the disk, it is a stray read.
We need to figure out from where the read is coming?

The noflush deamon is run with verbose output by RAIDator, but it seems possible to add even more debug text according to the manual page I've read.
http://pwet.fr/man/linux/administration_systeme/noflushd

The -d option adds more output to syslog, the only problem is that -d is preventing "daemonzing", the daemon will not fork and put itself as a background process.

To get more output into the syslog I believe you will need to:
a) SSH into the box
b) Kill the running noflushd instance
c) Restart a new noflushd with "noflushd -v -d -n 60" (if 60 minutes is your spindown delay as mine is)
d) Keep the SSH open until the problem is back and then look for additonal output in the SSH session.
e) Stop noflushd with e.g. CTRL-C and restart it normally (just remove -d) and it should daemonize.
It might be possible to do c) above as a background process with output to syslog or any other log file of your choice, e.g.
# nohup noflush -v -d -n 60 > /var/log/noflushd.log 2>&1 &

If anything goes wrong it should be just to restart the box to resume normal operation.

I might try this out when I've gathered some more statistics on my drive.

To make the scene more complex, I just added a nice squeezebox to my network today - nice getting rid of that old CD-player...
... but hunting spurious spinups might become more difficult if the squeezebox is talking to the NAS at random/undesired times?

/f

Wow thats a lot of concern for sleeping disks! :slap: