Dynamix - V6 Plugins

[RobJ]

My system is only using user shares which I understand are already managed in memory.  Does that make Cache Dirs unnecessary for those types of set ups?

Could you give a reference for your understanding that user shares are already managed in memory?

The User Share file system is a virtual file system built by FUSE in memory, which should make it unnecessary (and wasteful and inefficient) to require caching it in additional memory.  I've always felt that CacheDirs is not useful at all for User Shares, but I vaguely remember a very knowledgeable user saying there WAS a use in certain circumstances, which I don't remember.  I'd say uninstall CacheDirs and see if you ever spin spun-down drives up while browsing the shares.

[trurl]

My system is only using user shares which I understand are already managed in memory.  Does that make Cache Dirs unnecessary for those types of set ups?

Could you give a reference for your understanding that user shares are already managed in memory?

The User Share file system is a virtual file system built by FUSE in memory, which should make it unnecessary (and wasteful and inefficient) to require caching it in additional memory.  I've always felt that CacheDirs is not useful at all for User Shares, but I vaguely remember a very knowledgeable user saying there WAS a use in certain circumstances, which I don't remember.  I'd say uninstall CacheDirs and see if you ever spin spun-down drives up while browsing the shares.

OK. I found Joe L. post in original thread. I had thought that if you run it on the drives the user shares already got the benefit. Did he mean the user shares already have them cached even if you don't run it at all?

[JonathanM]

OK. I found Joe L. post in original thread. I had thought that if you run it on the drives the user shares already got the benefit. Did he mean the user shares already have them cached even if you don't run it at all?

Yes and no, sort of.

User shares are indeed built and run in memory, but that memory can be claimed by any and all other processes. When something is accessed, the disks are spun up to rebuild that portion of the user share fs. Cache dirs keeps the underlying disks contents fresh in memory, so accesses are nearly instantaneous. So to answer the OP's question directly, you will see a benefit from running cache dirs on the DISKS that make up the user share that you wish to cache, as long as you have enough RAM so the directory tree can actually stay cached without being overrun by other processes. Whether or not you use disk shares has no bearing on cache dirs being useful to user shares. Where people are running into issues is trying to use cache dirs to keep too much of the directory tree in memory, as that causes cache dirs to keep the disks spun up because as soon as it's done walking the disk, something else comes along and needs that RAM, knocking the directory list out, causing the disk to stay spun up as cache dirs reads it into RAM again, causing a loop.

[trurl]

OK. I found Joe L. post in original thread. I had thought that if you run it on the drives the user shares already got the benefit. Did he mean the user shares already have them cached even if you don't run it at all?

Yes and no, sort of.

User shares are indeed built and run in memory, but that memory can be claimed by any and all other processes. When something is accessed, the disks are spun up to rebuild that portion of the user share fs. Cache dirs keeps the underlying disks contents fresh in memory, so accesses are nearly instantaneous. So to answer the OP's question directly, you will see a benefit from running cache dirs on the DISKS that make up the user share that you wish to cache, as long as you have enough RAM so the directory tree can actually stay cached without being overrun by other processes. Whether or not you use disk shares has no bearing on cache dirs being useful to user shares. Where people are running into issues is trying to use cache dirs to keep too much of the directory tree in memory, as that causes cache dirs to keep the disks spun up because as soon as it's done walking the disk, something else comes along and needs that RAM, knocking the directory list out, causing the disk to stay spun up as cache dirs reads it into RAM again, causing a loop.

OK, that's basically the way I thought it worked. My users and my apps are only given access to user shares and I only access disk shares as root from telnet when needed. I had thought my user shares benefitted from cache-dirs and that's what it sounds like you are saying. I have plenty of RAM so haven't ever had an issue with spinning drives because of cache-dirs.

[thespooler]

User shares are indeed built and run in memory, but that memory can be claimed by any and all other processes. When something is accessed, the disks are spun up to rebuild that portion of the user share fs. Cache dirs keeps the underlying disks contents fresh in memory, so accesses are nearly instantaneous. So to answer the OP's question directly, you will see a benefit from running cache dirs on the DISKS that make up the user share that you wish to cache, as long as you have enough RAM so the directory tree can actually stay cached without being overrun by other processes. Whether or not you use disk shares has no bearing on cache dirs being useful to user shares. Where people are running into issues is trying to use cache dirs to keep too much of the directory tree in memory, as that causes cache dirs to keep the disks spun up because as soon as it's done walking the disk, something else comes along and needs that RAM, knocking the directory list out, causing the disk to stay spun up as cache dirs reads it into RAM again, causing a loop.

 

So how do you know when the files listing memory is getting freed up?  Is there a log entry indicating the memory has been released?  Or is there a log entry that the file system has been read, which would give you an indication that they were flushed?

[Endy]

I've been searching, but I must not be using the right terms.

 

I have System Temp installed and drivers loaded and there are 4 sensors listed. k10temp, it8720 temp1, it8720 temp2, it8720 temp3.

 

My question is, which sensor is which? I am thinking that k10temp is the processor and the other 3 are different locations on the motherboard? If so, which one do I assign to motherboard? (All are between 20 and 30 degrees except for temp3 which is about 78 degrees.)

[JonathanM]

So how do you know when the files listing memory is getting freed up?

No logging that I am aware of. It's kernel memory, so it just does its thing invisibly in the background. If a directory list event causes a drive access, then either the list is no longer in RAM, or it wasn't just a file list request, but content as well. Most gui file managers try to display some form of thumbnail unless you turn that feature off, so if a drive spins up when you browse it, make sure the program isn't doing anything but listing the file names.

[kizer]

Every time I try to remove Dynamix System Statistics even thou its an awesome looking Plugin, I just don't honestly need to use it all the time. I get this same message that repeats over and over in my logs. I found the cron entry in /etc/cron.d/root

 

*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null

 

I removed it I still keep getting that error message. Am I missing something some where else?

[bonienl]

Every time I try to remove Dynamix System Statistics even thou its an awesome looking Plugin, I just don't honestly need to use it all the time. I get this same message that repeats over and over in my logs. I found the cron entry in /etc/cron.d/root

 

*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null

 

I removed it I still keep getting that error message. Am I missing something some where else?

 

I need to update the PLG to stop the background service when the plugin is uninstalled.

 

You can do that manually, type the following after the uninstall:

 

update_cron

 

[danioj]

I have just updated System Stats from 2015.12.19b to 2016.01.13. I noticed that the nice feature - "Placement of Stats menu" - allows the menu to move away from the header. As you know I have issues with space on Safari on my iDevices. Nice that you have given more ability to adapt to the top menu.

 

Unfortunately it didn't work. Then I noticed this in the release notes:  (requires unRAID 6.1.7 or higher)

 

Is this a typo or are we expecting a pending release?

 

All working now after - the release of - and - my subsequent upgrade to - 6.1.7. Thank you, nice option.

[dlandon]

Just updated to the new webgui and with the unassigned devices plugin installed, the webgui created the default unassigned devices page so there is now the default one and the unassigned devices plugin page.  I had to uninstall the unassigned devices plugin and reinstall to clean it up.

 

Any suggestions on how we can make this update work cleaner?

[clevoir]

I have just updated to the lastest version of the Dynamix plugin, now I can't access the array. It still works OK but on trying to access the GUI using the array's IP address, the browswe reports 404 file not found I am running 6.1.7

 

Help!

 

I do have a backup of the flash drive taken before I updatd the plugin that I could always copy back to the flash drive, but I am concerned that it might happen again should to try to update the plugin

[saarg]

I have just updated to the lastest version of the Dynamix plugin, now I can't access the array. It still works OK but on trying to access the GUI using the array's IP address, the browswe reports 404 file not found I am running 6.1.7

 

Help!

 

I do have a backup of the flash drive taken before I updatd the plugin that I could always copy back to the flash drive, but I am concerned that it might happen again should to try to update the plugin

See the post here.

[clevoir]

Deleting dynamix-2016.01.22.tar.gz from /boot/config/plugins/dynnamix worked for me too

 

Thanks

[El Gabito]

I have an MSI z97 Gaming 5 motherboard. How do I find drivers to get other than "coretemp"? Kind of new to this stuff.

 

Here is the output of "sensors-detect":

 

root@Tower:~# sudo sensors-detect
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: MSI MS-7917 [1.0]
# Board: MSI Z97 GAMING 5 (MS-7917)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): YES
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): YES
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               Yes
Found unknown chip with ID 0xc911

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): YES
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): YES
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): YES
Found unknown SMBus adapter 8086:8ca2 at 0000:00:1f.3.
Sorry, no supported PCI bus adapters found.

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): NO
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):

#----cut here----
# Chip drivers
modprobe coretemp
/usr/bin/sensors -s
#----cut here----

If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones! You really
should try these commands right now to make sure everything is
working properly. Monitoring programs won't work until the needed
modules are loaded.

[Squid]

I have an MSI z97 Gaming 5 motherboard. How do I find drivers to get other than "coretemp"? Kind of new to this stuff.

 

Here is the output of "sensors-detect":

 

root@Tower:~# sudo sensors-detect
# sensors-detect revision 6170 (2013-05-20 21:25:22 +0200)
# System: MSI MS-7917 [1.0]
# Board: MSI Z97 GAMING 5 (MS-7917)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): YES
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Intel digital thermal sensor...                             Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): YES
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               Yes
Found unknown chip with ID 0xc911

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): YES
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): YES
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): YES
Found unknown SMBus adapter 8086:8ca2 at 0000:00:1f.3.
Sorry, no supported PCI bus adapters found.

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO): NO
To load everything that is needed, add this to one of the system
initialization scripts (e.g. /etc/rc.d/rc.local):

#----cut here----
# Chip drivers
modprobe coretemp
/usr/bin/sensors -s
#----cut here----

If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones! You really
should try these commands right now to make sure everything is
working properly. Monitoring programs won't work until the needed
modules are loaded.

Try a later version of sensors-detect.  The website looks like its completely defunct, but you can get the latest version here:

 

http://lime-technology.com/forum/index.php?topic=36543.msg430371#msg430371

[glave]

In regards to the stats plugin,

 

I have unraid send notifications to me via Pushbullet. The stats plugin has default values for disk space usage set to (Warning) 70% = High, (Alert) 90% = Low on space.

 

Is there somewhere I can tweak those values? It would be really great if it's possible to not only choose the threshold, but also choose it on an individual drive level (or at least the cache drive), and change the type of notification level that it is (Warning,Alert,etc).

 

Is any piece of this currently possible?

[Squid]

In regards to the stats plugin,

 

I have unraid send notifications to me via Pushbullet. The stats plugin has default values for disk space usage set to (Warning) 70% = High, (Alert) 90% = Low on space.

 

Is there somewhere I can tweak those values? It would be really great if it's possible to not only choose the threshold, but also choose it on an individual drive level (or at least the cache drive), and change the type of notification level that it is (Warning,Alert,etc).

 

Is any piece of this currently possible?

Disk Settings (but you can't change the alert level (notification, warning, alert) )

[glave]

]Disk Settings (but you can't change the alert level (notification, warning, alert) )

 

Where at? I've looked in the Stats settings & Disk Settings and I do not see the thresholds.

[wgstarks]

]Disk Settings (but you can't change the alert level (notification, warning, alert) )

 

Where at? I've looked in the Stats settings & Disk Settings and I do not see the thresholds.

[glave]

]Disk Settings (but you can't change the alert level (notification, warning, alert) )

 

Where at? I've looked in the Stats settings & Disk Settings and I do not see the thresholds.

 

Geez, I have no clue what I'm drinking today, because I STILL didn't see it when I went back to the page because I was convinced that you were somehow wrong!  Maybe I need to get my glasses updated...

 

Thanks

[itimpi]

Geez, I have no clue what I'm drinking today, because I STILL didn't see it when I went back to the page because I was convinced that you were somehow wrong!  Maybe I need to get my glasses updated...

Worth pointing out that you can set over-rides for individual disks by going to the settings for that disk (in case you also missed those  )

[glave]

Geez, I have no clue what I'm drinking today, because I STILL didn't see it when I went back to the page because I was convinced that you were somehow wrong!  Maybe I need to get my glasses updated...

Worth pointing out that you can set over-rides for individual disks by going to the settings for that disk (in case you also missed those  )

 

 

And now my day is complete!  Thank you very much for that sir!  Now my enormous drives will let me know when they get truly low on space and my cache drive will let me know when sonarr has went on a frenzy before the mover could kick in to give cache some wiggle room back.

 

 

[John_M]

Just updated to the new webgui and with the unassigned devices plugin installed, the webgui created the default unassigned devices page so there is now the default one and the unassigned devices plugin page.  I had to uninstall the unassigned devices plugin and reinstall to clean it up.

 

Any suggestions on how we can make this update work cleaner?

 

For me it broke two other plugins but both were fixed by uninstalling them and then reinstalling. They were the Dynamix SSD Trim plugin, which disappeared from the Settings - Scheduler page, and the Dynamix Local Master plugin, which added the following error message to the syslog every minute:

 

Jan 23 20:08:01 Lapulapu crond[1493]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix/scripts/localmaster &> /dev/null
Jan 23 20:09:01 Lapulapu crond[1493]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix/scripts/localmaster &> /dev/null
Jan 23 20:10:01 Lapulapu crond[1493]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix/scripts/localmaster &> /dev/null

 

[interwebtech]

Just updated to the new webgui and with the unassigned devices plugin installed, the webgui created the default unassigned devices page so there is now the default one and the unassigned devices plugin page.  I had to uninstall the unassigned devices plugin and reinstall to clean it up.

 

Any suggestions on how we can make this update work cleaner?

 

For me it broke two other plugins but both were fixed by uninstalling them and then reinstalling. They were the Dynamix SSD Trim plugin, which disappeared from the Settings - Scheduler page, and the Dynamix Local Master plugin, which added the following error message to the syslog every minute:

 

Jan 23 20:08:01 Lapulapu crond[1493]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix/scripts/localmaster &> /dev/null
Jan 23 20:09:01 Lapulapu crond[1493]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix/scripts/localmaster &> /dev/null
Jan 23 20:10:01 Lapulapu crond[1493]: exit status 127 from user root /usr/local/emhttp/plugins/dynamix/scripts/localmaster &> /dev/null

 

my log is full of these too. reinstalling them now.