NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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...
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
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).
->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).
I don't have any apps installed, but the rsyslog was still active. For now I just deactivated it with systemctl disable rsyslog.
->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.
So, without rsyslog running:
Jun 14 14:26:49 NAS noflushd[30958]: Spinning up disk 1 (/dev/sda) after 7:45:55. Jun 14 14:26:49 NAS noflushd[30958]: Spinning up disk 2 (/dev/sdb) after 7:45:52.
that is OK
But hier I still have some questions
Jun 14 14:56:50 NAS noflushd[30958]: Spinning down disk 1 (/dev/sda). Jun 14 14:56:53 NAS noflushd[30958]: Spindown of disk 1 (/dev/sda) cancelled. Jun 14 14:56:53 NAS noflushd[30958]: Spinning down disk 2 (/dev/sdb). Jun 14 15:09:11 NAS noflushd[30958]: Spinning up disk 2 (/dev/sdb) after 0:12:16. Jun 14 15:32:12 NAS noflushd[30958]: Spinning down disk 1 (/dev/sda). Jun 14 15:32:15 NAS noflushd[30958]: Spinning down disk 2 (/dev/sdb). Jun 14 16:17:13 NAS noflushd[30958]: Spinning up disk 1 (/dev/sda) after 0:44:58. Jun 14 16:32:15 NAS noflushd[30958]: Spinning down disk 1 (/dev/sda).
I think, it may be caused by the journalctl or some other logging daemon, at this time of the day the was nobody at home using the nas
->Writing logs to RAM sounds like a bad idea to me, as you'd likely lose them when you need them the most.
the RAM thing was actually temporary and used only for a daemon.log, I needed a log that wouldn't be written on the root system for the noflushd. At this time I have no knowledge of the journalctl.
For the tallylog - I'm sure it was updated due to some cron jobs or some other activity from readynasd, The configuration for tallylog is in the pam.d file for 'frontview' service. I don't know what is it, but the tallylog was written without any user been logging in.
So my suggestion is sitll to transfer all kind of system stuff aka logging to the USB and the /tmp to the tmpfs drive.
vbif wrote:
I think, it may be caused by the journalctl or some other logging daemon, at this time of the day the was nobody at home using the nas
At this time I have no knowledge of the journalctl.
It's easy to confirm that, just run journalctl from ssh and look for log entries made at about those times. Journalctl is easy to use, just google it and you'll find several guides. There are other possibilities (snapshots being taken being one of several).
I get that spindown/spinup often does give you fairly short spindown times - and FWIW I think Netgear could do a better job of testing for regressions in this area when they update firmware.
But is there a reason that you need to be so aggressive on eliminating all spinups? The changes you are making might cause you problems when you update firmware (or maybe even when hotfixes are applied). If you're lucky they will just be overwritten by the new firmware from time to time. And you'll still end up with the USB drive spinning up.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
