Help With getting higher than SMB1 on nsa320

mdbarber

Mijzelf said:

any ideas please?

The package 'Tweaks' has a function 'Disk Monitor' which is meant to find out what keeps your disk(s) awake.

not sure i can make sense of this, the log shows constant access via the cache being flushed and the journal updating, this seems to occur even when only the disk monitor is being used.

I have been thru and disabled via webmin or tweak util,  pretty much everything but essentials.
 and surely that util should log to ram to prevent it causing the disks to wake?, the disks will go to sleep, eventually but this system access is strange.

As a side note,  sorry for late delay but i later found out the smb3 update also knocked out the print server on the nsa when i limited my win10 machine to smb3 only, so i had to re enable smb1 until i can get spare time to investigate properly.

Mijzelf

not sure i can make sense of this, the log shows constant access via the cache being flushed and the journal updating, this seems to occur even when only the disk monitor is being used.

Can you share a relevant part of the log?

mdbarber

Mijzelf said:

not sure i can make sense of this, the log shows constant access via the cache being flushed and the journal updating, this seems to occur even when only the disk monitor is being used.

Can you share a relevant part of the log?

sure, have attached one here, i had disabled pretty much everything unnecess and a thing i would prefer not to but it made no difference even after waiting a couple of hours.

Mijzelf

It's not that bad. A quick summary tells that the disks are waked up 3 times in 3 hours in that logfile

$ grep '====\|awake\|stand by' pkgcgi2.txt
==== Mon Jul 25 13:38:54 WEST 2022 ====
*            HD0 stand by now!        *
*            HD1 stand by now!        *
#              HD0 awaked by swapper  !        #
#              HD1 awaked by swapper !        #
==== Mon Jul 25 13:39:06 WEST 2022 ====
==== Mon Jul 25 13:44:55 WEST 2022 ====
*            HD0 stand by now!        *
*            HD1 stand by now!        *
==== Mon Jul 25 14:28:38 WEST 2022 ====
#              HD0 awaked by swapper  !        #
#              HD1 awaked by swapper !        #
==== Mon Jul 25 14:29:22 WEST 2022 ====
==== Mon Jul 25 14:30:02 WEST 2022 ====
==== Mon Jul 25 14:31:08 WEST 2022 ====
==== Mon Jul 25 14:32:03 WEST 2022 ====
==== Mon Jul 25 14:33:09 WEST 2022 ====
==== Mon Jul 25 14:34:03 WEST 2022 ====
==== Mon Jul 25 14:35:08 WEST 2022 ====
==== Mon Jul 25 14:40:56 WEST 2022 ====
*            HD0 stand by now!        *
*            HD1 stand by now!        *
==== Mon Jul 25 15:24:51 WEST 2022 ====
#              HD0 awaked by swapper  !        #
#              HD1 awaked by swapper !        #
==== Mon Jul 25 15:25:00 WEST 2022 ====

The first time it's not clear why. Among other things the file zypkg.log is dirtied by zyshd. So it has something to do with package management, which it shouldn't do with sleeping disks. But as the sleeping and awaking of the disks happened within 12 seconds, it could be some internet action which started before the sleep, and finished after.

Both other wakings are caused by weblogin.cgi. Do you have exposed your webinterface to outside? It could be internet noise.

mdbarber

Mijzelf said:

It's not that bad. A quick summary tells that the disks are waked up 3 times in 3 hours in that logfile

$ grep '====\|awake\|stand by' pkgcgi2.txt
==== Mon Jul 25 13:38:54 WEST 2022 ====
*            HD0 stand by now!        *
*            HD1 stand by now!        *
#              HD0 awaked by swapper  !        #
#              HD1 awaked by swapper !        #
==== Mon Jul 25 13:39:06 WEST 2022 ====
==== Mon Jul 25 13:44:55 WEST 2022 ====
*            HD0 stand by now!        *
*            HD1 stand by now!        *
==== Mon Jul 25 14:28:38 WEST 2022 ====
#              HD0 awaked by swapper  !        #
#              HD1 awaked by swapper !        #
==== Mon Jul 25 14:29:22 WEST 2022 ====
==== Mon Jul 25 14:30:02 WEST 2022 ====
==== Mon Jul 25 14:31:08 WEST 2022 ====
==== Mon Jul 25 14:32:03 WEST 2022 ====
==== Mon Jul 25 14:33:09 WEST 2022 ====
==== Mon Jul 25 14:34:03 WEST 2022 ====
==== Mon Jul 25 14:35:08 WEST 2022 ====
==== Mon Jul 25 14:40:56 WEST 2022 ====
*            HD0 stand by now!        *
*            HD1 stand by now!        *
==== Mon Jul 25 15:24:51 WEST 2022 ====
#              HD0 awaked by swapper  !        #
#              HD1 awaked by swapper !        #
==== Mon Jul 25 15:25:00 WEST 2022 ====

The first time it's not clear why. Among other things the file zypkg.log is dirtied by zyshd. So it has something to do with package management, which it shouldn't do with sleeping disks. But as the sleeping and awaking of the disks happened within 12 seconds, it could be some internet action which started before the sleep, and finished after.

Both other wakings are caused by weblogin.cgi. Do you have exposed your webinterface to outside? It could be internet noise.

Hi
no, the web interface port is not open on the router, i haven't had much chance to investigate since my print function went down i had to revert back to smb1 but previously i did seem to notice the disks always appeared to be awake whenever i tried to access them, there appeared to be no spinup lag so i had assumed they weren't sleeping at all.