cache_dirs - an attempt to keep directory entries in RAM to prevent disk spin-up

[dlandon]

46 minutes ago, jeff.lebowski said:

Is the new one v 2.2.8?

Yes, cache_dirs 2.2.8.  The only changes are to the GUI.

[xreyuk]

I'm now having the spiking CPU issue with the latest version of Cache Dirs. The below is from a 30 second window of CPU activity.

 

I didn't have this problem with the old 'incompatible' one. 

 

 

My settings are whatever defaults come with the plugin (including /mnt/user scanning turned off), except I have removed any directories on my cache, so only have array drives cached by the plugin, none of which are written to at the time (the disks are all spun down). These are the settings I've always had and it's been fine.

 

Disabling the plugin completely stops this behavior.

 

Any ideas?

Edited April 28 by xreyuk

[dlandon]

1 hour ago, xreyuk said:

I'm now having the spiking CPU issue with the latest version of Cache Dirs. The below is from a 30 second window of CPU activity.

 

I didn't have this problem with the old 'incompatible' one. 

 

 

My settings are whatever defaults come with the plugin (including /mnt/user scanning turned off), except I have removed any directories on my cache, so only have array drives cached by the plugin, none of which are written to at the time (the disks are all spun down). These are the settings I've always had and it's been fine.

 

Disabling the plugin completely stops this behavior.

 

Any ideas?

Nothing in the cache_dirs script has changed.  Setup cache_dirs to cache only one share and then watch the CPU activity.  Then add one at a time to see which one spikes the CPU.

[xreyuk]

35 minutes ago, dlandon said:

Nothing in the cache_dirs script has changed.  Setup cache_dirs to cache only one share and then watch the CPU activity.  Then add one at a time to see which one spikes the CPU.

Thanks, I think it may have been my 'snapshots' dir causing it. I use SpaceInvaderOne's replication script to replicate my ZFS cache snapshots to the array. It's possible I didn't have this in the previous caching as it would have been setup after Cache Dirs was setup, however I didn't think adding a share to cache dirs would have caused such a cpu spike!

 

I'm seeing smaller cpu jumps over the same time period, which is only minor, but is there a setting I can use to adjust these? I don't write to the array very often so probably don't cache dirs updating this often.

Edited April 28 by xreyuk

[dlandon]

48 minutes ago, xreyuk said:

Thanks, I think it may have been my 'snapshots' dir causing it. I use SpaceInvaderOne's replication script to replicate my ZFS cache snapshots to the array. It's possible I didn't have this in the previous caching as it would have been setup after Cache Dirs was setup, however I didn't think adding a share to cache dirs would have caused such a cpu spike!

The idea behnid the recent changes to the GUI was to keep cache_dirs under control.  If a person was to install the old cache_dirs and not make any include or exclude share settings, cache_dirs would cache anything that showed up at /mnt/.  That includes UD disks and remote shares.  Caching those would cause some errors with CIFS mounts.  I'm not surprised certain shares would cause CPU spikes.  I guess it depends on the file structure.  It should never be setup to cache shares if not necessary.  For example, the 'appdata' and 'system' shares are not even choices because they should reside on SSD drives and caching those is not necessary.

 

57 minutes ago, xreyuk said:

I'm seeing smaller cpu jumps over the same time period, which is only minor, but is there a setting I can use to adjust these? I don't write to the array very often so probably don't cache dirs updating this often.

There are a lot of settings to control the cache_dirs script operation.  You should read the documentation and determine if there are any setting changes appropriate to your situation.

[JC-303]

Thank you for creating this script.  I've tried searching the history here and saw a couple of very old posts saying that the -e command for excluding directories won't work on subdirectories.  Is that still the case?  I have a couple of subdirectories with hundreds of thousands of small files that I really don't want to include in the scanning and am not sure if putting them in the user defined options like this will have any effect when /mnt/user/backup is an included directory?

 

-a '-e /mnt/user/backup/directory-to-avoide -e /mnt/user/backup/another-directory-to-avoid'

 

Thank you.