When I do a library update in Kodi, it will spin up like 5 of my 13 disks. I have no local art on them, and cache_dir is running with 16GB of RAM. It really shouldn't require a disk spinup to check if anything has changed? I'm hoping cache_dirs can be adjusted to keep this stuff in the RAM. I am running default settings with cache user shares selected.

 

Is there anyway to stop this from happening?

Edited April 15, 20179 yr by tyrindor

Kept searching, and came across a cache_dirs section of the upgrading guide and I think it may have fixed it. Changed a few settings, restarted server, did a Kodi library update (with no changes) and got 0 reads from all disks. Hopefully it sticks.

 

http://lime-technology.com/wiki/index.php/Upgrading_to_UnRAID_v6

 

Quote

CacheDirs - forces dir entries to stay cached, allowing drives to spin down

• It is called Dynamix Cache Directories on the Plugins page, and Folder Caching on the Settings tab.
• If you have been running CacheDirs from the go file, that won't be necessary any more, and you will want to install this plugin instead to get the same benefits.
• After you install the Cache Directories plugin, go to the Settings page, click the Folder Caching icon, first enable the Folder caching function, then configure it as desired, and click the Apply button.
• If you were running it in v4 or v5 and want to find the old settings you have been using, refer to your go file in the config folder of your v4 or v5 backup, and look for the cache_dirs command line.
• It defaults to including all top level folders, if you don't specify the Included folders. There is a small bug in the current version that may cause some folders to not be cached some of the time, if set to All folders (nothing set in Included folders). It is therefore strongly recommended (you're probably tired of all these 'strong recommendations'!) that you do select the exact folders you want cached. Just click in the field box, and a list of all top level folders will be presented for you to check or leave unchecked. Only check those that it would be useful to cache, because caching takes memory, no need to waste it!
• CacheDirs has a couple of small but hidden side-effects that may or may not be suitable for your v6 installation. Both of these system tweaks were added originally to CacheDirs to allow users to run successfully in only 512MB. That's rarely necessary any more.
  • CacheDirs modifies the process virtual memory limit, uses ulimit to set it to '50000' for 64 bit systems like unRAID v6 ('5000' for others). The Linux system default is 'unlimited'.

  Since v6 users generally have plenty of memory, and to avoid any possible side-effects, it is suggested to add the parameter -U 0 (that's a capital U and a zero) to the User defined options field on the Folder Caching settings page. Setting it to zero keeps CacheDirs from modifying it.

  • CacheDirs modifies vm.vfs_cache_pressure, a system parameter governing how aggressively the file and folder dir entries are kept in a cache. The Linux system default is '100', which is considered a "fair" value. Lower values like '1' or '10' or '50' will keep more dir entries cached, '200' would allow them to be more easily dropped, resulting in more drive spinups. The most aggressive would be '0', but unfortunately it may introduce a small risk of out-of-memory conditions, when other memory needs cannot be satisfied because dir entries are hogging it!

  By default, CacheDirs sets it to '10', which is a good value for most users. If you set it to '100', then it will remain the same as the Linux default value.

  If you wish to change it, add a -p # (that's a lowercase p and a number) to the User defined options field on the Folder Caching settings page. For example, to set it to more aggressively protect your cached dir entries, enter -p 1 in the options field. To avoid any possible side effects, add the parameter -p 100, which will restore it to the system default.

• Most users should leave Scan user shares set to No. Since the User Shares are created and managed in memory, it makes little sense to cache them in more memory!
• Except for those already mentioned, the rest of the fields are fine with their default values.

 

 

Edited April 17, 20179 yr by tyrindor