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

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.

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.