NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

vbif's avatar
vbif
Aspirant
Jun 10, 2019

Spin-down problem and how I resolved it

Since the Spin-down option was built in it has been never working properly. After each and every Update (wich I appreciate a lot by the way) I've been trying to activate this function always with the same result: the noflushd starts to spinning down the disks and then cancelled it or spins the disks up after a very short time:

Jun  9 13:51:25 NAS noflushd[1219]: Spinning down disk 1 (/dev/sda).
Jun  9 13:51:28 NAS noflushd[1219]: Spinning down disk 2 (/dev/sdb).
Jun  9 13:52:01 NAS noflushd[1219]: Spinning up disk 1 (/dev/sda) after 0:00:33.
Jun  9 13:52:01 NAS noflushd[1219]: Spinning up disk 2 (/dev/sdb) after 0:00:31.

So, as lazy as I was all this time, I think I have a solution now. The big problem for the spin-down function on the rn102 system is that the root file system is located on the disks (/dev/md0) itself, the /var/log is located there, the /tmp !!! is located there. So we have a problem here, there are so many processes that continuously writes and logs to the disks so that noflushd has to spin up the disks over and over again.

I do some changes to my system, and now I see that noflushd keep disks down for hours!

 

Jun 10 07:27:43 NAS noflushd[12648]: Spinning down disk 1 (/dev/sda).
Jun 10 07:27:45 NAS noflushd[12648]: Spinning down disk 2 (/dev/sdb).
Jun 10 11:02:59 NAS noflushd[12648]: Spinning up disk 1 (/dev/sda) after 3:35:14.
Jun 10 11:02:59 NAS noflushd[12648]: Spinning up disk 2 (/dev/sdb) after 3:35:11.

Hier are the changes I've made:

/etc/pam.d/frontview

#%PAM-1.0
#auth       requisite    pam_tally2.so  onerr=fail deny=5 unlock_time=300
auth       required     pam_unix.so
#account    required     pam_tally2.so
account    required     pam_unix.so

the first and the third lines were commented out, so that the /var/log/tallylog is no longer updated. I think, on my system with only access from home network I could give up a small security feature for a better power consumption.

then the /etc/rsyslog.conf was modified so that only .err messages are been writen to /var/log/...

auth,authpriv.err			/var/log/auth.log
*.err;auth,authpriv.none		-/var/log/syslog
daemon.err			-/var/log/daemon.log
daemon.*			/run/lock/daemon.log
kern.*				/run/lock/kern.log
kern.err				-/var/log/kern.log
lpr.err				-/var/log/lpr.log
mail.err				-/var/log/mail.log
user.err				-/var/log/user.log

 the daemon.log and the kern.log are now located at /run/lock wich lives in ram. I know, /run/lock is not a suitable place for logs, but it is only tmfs partitions big enough to hold the logs.  The daemon.log is usefull to track down the noflushd work. 

 

My plan is to use USB flash drive for all the logs, and to change the /tmp to the tmpfs file system so that noflushd have acctually some chance to spin down the disks.

 

I run the latest firmware 6.10.1

5 Replies

Replies have been turned off for this discussion
  • StephenB's avatar
    StephenB
    Guru - Experienced User

    I don't have many of the log files you reference (and don't have /etc/rsyslog.conf either).  Normally the NAS logging is done with journalctl.

     

    I am thinking you might have installed rsyslog manually - is that the case?

    • vbif's avatar
      vbif
      Aspirant

      that is an interesting point. But I haven't installed rsyslog manually, may be it came with some Netgear apps as a dependence, I did test some of them.

      by the way journalctl also writes to the root aka md0

      • StephenB's avatar
        StephenB
        Guru - Experienced User

        vbif wrote:

        that is an interesting point. But I haven't installed rsyslog manually, may be it came with some Netgear apps as a dependence, I did test some of them.


        There is (or was) a log monitoring app that installs rsyslog.  I suggest uninstalling any apps you no longer use (and if you've done that already, manually uninstall rsyslog).  Some of them can destabilize the NAS (particularly when upgrading firmware).

         


        vbif wrote:

        by the way journalctl also writes to the root aka md0


        Yes of course.  But you got spindown to work without changing journalctl.  My recollection is that Netgear set up logging to defer writes (at least to some degree) in order to avoid spinup.  There are some posts where they say they said that they made some adjustments to flushd.

         

        FWIW, I wouldn't have made your mods - at least not all of them.  /tmp is rarely used, so I'd leave that alone.  Writing logs to RAM sounds like a bad idea to me, as you'd likely lose them when you need them the most.  I think tallylog is normally updated when users attempt to log in - which likely will spin up the disks anyway.  So I wouldn't be inclined to fiddle with pam or tallylog either.

         

        But it'd be interesting to see the results of making each mod individually (after removing rsyslog, and seeing what difference that makes).

         

         

NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology! 

Join Us!

ProSupport for Business

Comprehensive support plans for maximum network uptime and business peace of mind.

 

Learn More