Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

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

Featured Replies

Am running 5.0rc5 and i dont have cache drive, so the mover cant cause that in my case since script isnt runned.

I have disable all crontab, will see if that happen again ... if not i will investigate on those :)

  • Replies 1.2k
  • Views 460.7k
  • Created
  • Last Reply

Top Posters In This Topic

Most Popular Posts

  • Alex R. Berg
    Alex R. Berg

    Hey yo all,   I'm the last active maintainer of the plugin cache-dir script (I guess since Joe wrote it). There's 'complaints' for a long time here, that cache-dir spikes CPU, and I finally

  • There is a replacement cache_dirs plugin that should solve several of the issues here.  Uninstall the current cache_dirs then go to CA and install the new one.  You will notice that the 'exclude' fold

  • Alex R. Berg
    Alex R. Berg

    It looks good interwebotech, so your problem is not the line i noticed had changed.    After I sent the message I noticed I completely had missed pulling all the changes from the release-rep

Posted Images

Feb 10 05:34:25 Tower kernel: mdcmd (112): spindown 3

Feb 10 05:34:25 Tower kernel: mdcmd (113): spindown 4

 

This night once again, all the crontab was disable.

Can't be the "/usr/local/sbin/mover" script, since the head of the script block execution since i dont have cache dir.

 

What can it be?

  • Author

Feb 10 05:34:25 Tower kernel: mdcmd (112): spindown 3

Feb 10 05:34:25 Tower kernel: mdcmd (113): spindown 4

 

This night once again, all the crontab was disable.

Can't be the "/usr/local/sbin/mover" script, since the head of the script block execution since i dont have cache dir.

 

What can it be?

I'm thinking it can, since to perform the test it has to evaluate the path /mnt/ then get the set of inodes (information nodes hold directory and file names) that define the directories under it, then see if one of them matches /mnt/user0  Those directory inodes are on the disks... and if not in the disk buffer cache will need to spin up the disk associated.

 

That would potentially cause any disk under /mnt to spin up.

 

You can just type

mv /usr/local/sbin/mover /usr/local/sbin/mover.old

to disable it.

  • Author

Feb 10 05:34:25 Tower kernel: mdcmd (112): spindown 3

Feb 10 05:34:25 Tower kernel: mdcmd (113): spindown 4

 

This night once again, all the crontab was disable.

Can't be the "/usr/local/sbin/mover" script, since the head of the script block execution since i dont have cache dir.

 

What can it be?

I'm thinking it can, since to perform the test it has to evaluate the path /mnt/ then get the set of inodes (information nodes hold directory and file names) that define the directories under it, then see if one of them matches /mnt/user0  Those directory inodes are on the disks... and if not in the disk buffer cache will need to spin up the disk associated.

 

That would potentially cause any disk under /mnt to spin up.

 

You can just type

mv /usr/local/sbin/mover /usr/local/sbin/mover.old

to disable it.

 

Have you tried using "inotifywatch" to see exactly what is being accessed? 

 

Joe L.

True, nice point Joe.

I renamed script, will see if disk still spinup, if yes will try to run inotifywatch :)

  • 2 weeks later...

Im sure this has been answered before but is it possible to have cache dirs script start on startup, its the only thing i have to do manually at the moment. I love cache dirs!

 

edit: Thanks Joe L :)

  • Author

Im sure this has been answered before but is it possible to have cache dirs script start on startup, its the only thing i have to do manually at the moment. I love cache dirs!

yes, easiest is to add

/boot/cache_dirs -w

to the end of the /boot/config/go

script.

You can add any other parameters you use when starting it, but make sure you use the -w option.  Also, of the command was downloaded to a directory other than /boot, change the path.

 

Joe L.

My array refuses to shut down and the following process is active, is this cache_dirs ?

 

4 D root     11947  8743  0  80   0 -   620 sleep_ 08:56 ?        00:00:01 find /mnt/disk8/Music -noleaf

 

My music dir is kind of large, could it be that it just needs to finish this dir (and since it is a large itunes library it might take some time) before it picks up the quit command in the syslog ?

  • Author

My array refuses to shut down and the following process is active, is this cache_dirs ?

 

4 D root     11947  8743  0  80   0 -   620 sleep_ 08:56 ?        00:00:01 find /mnt/disk8/Music -noleaf

 

My music dir is kind of large, could it be that it just needs to finish this dir (and since it is a large itunes library it might take some time) before it picks up the quit command in the syslog ?

That is exactly what will happen.  It only looks for the shut down in between each individual "find" command.

 

Joe L.

Thanks !  I have excluded Music now, there is no real reason for me to keep it up as all dirs are on one disk and WHEN I browse my music collection I will play songs to.

Weird problem. One of my shares is named TV Shows. cache_dirs is telling me a directory with that name doesn't exist. I've tried both TV\ Shows and "TV Shows" when running the command but get the same results.

 

root@Unraid:~# /usr/local/sbin/cache_dirs -w -B -u -m1 -M10 -d9999 -i Downloads -i Movies -i "TV Shows"
ERROR: included directory "TV Shows" does not exist.
cache_dirs process ID 9277 started, To terminate it, type: cache_dirs -q

root@Unraid:/mnt/user# /usr/local/sbin/cache_dirs -w -B -u -m1 -M10 -d9999 -i Downloads -i Movies -i TV\ Shows
ERROR: included directory "TV Shows" does not exist.
cache_dirs process ID 11203 started, To terminate it, type: cache_dirs -q

root@Unraid:/mnt/user# ls -l
total 8
drwxrwxrwx 1 nobody users   72 2013-02-25 10:30 Backups/
drwxrwxrwx 1 nobody users  120 2013-02-25 13:57 Downloads/
drwxrwxrwx 1 nobody users 7824 2013-02-25 10:39 Movies/
drwxrwxrwx 1 nobody users   48 2012-06-08 02:29 Movies-Unsorted/
drwxrwsrwx 1 nobody users   80 2013-02-25 10:39 Music/
drwxrwxrwx 1 nobody users   80 2013-02-25 13:57 TV\ Shows/
drwxrwxrwx 1 nobody users   72 2013-02-23 11:02 other/
drwxrwxrwx 1 nobody users  352 2013-01-27 23:09 plugins/

  • Author

Assuming I did not make a coding error, and assuming your directory name does not have a backslash in it, you should be able to use

-i "TV Shows"

 

How did you install cache_dirs???  Did you use the recently posted plugin?  Or download it from the first post in this thread?

 

What do you get when you check the md5sum:

cd /usr/local/sbin/cache_dirs

md5sum cache_dirs

25ce0b04e39d07bb85921d3f7e05a5e0  cache_dirs

 

root@Unraid:/usr/local/sbin# md5sum cache_dirs

25ce0b04e39d07bb85921d3f7e05a5e0  cache_dirs

 

root@Unraid:/usr/local/sbin# cache_dirs -V

cache_dirs version: 1.6.7

 

I believe it's being installed by the Simple Features plugin. However, I have the plugin disabled and manually set its parameters from my go script. And the share directory definitely does not have a backslash in it. However, I just tried "/usr/local/sbin/cache_dirs -w -B -u -m1 -M10 -d9999 -i Downloads -i Movies -i "TV\ Shows"" with the backslash in it and that worked without the error. Not sure why quotes and backslash are both necessary..

 

d7QrzAp.png

I'll talk to Bonienl to see if he modified the cache_dirs script in any way.

 

Looking at the checksum I presume not... 

 

Sorry Joe L. if this ends up being a GUI issue... 

I'll talk to Bonienl to see if he modified the cache_dirs script in any way.

 

Looking at the checksum I presume not... 

 

Sorry Joe L. if this ends up being a GUI issue...

 

Like I said though, I'm not configuring cache_dirs from your GUI. I'm configuring it from my go script. Your plugin is just installing cache_dirs but it isn't enabled in the GUI.

I'll talk to Bonienl to see if he modified the cache_dirs script in any way.

 

Looking at the checksum I presume not... 

 

Sorry Joe L. if this ends up being a GUI issue...

 

Like I said though, I'm not configuring cache_dirs from your GUI. I'm configuring it from my go script. Your plugin is just installing cache_dirs but it isn't enabled in the GUI.

 

Preemptive PR  ;)

  • Author

I'll talk to Bonienl to see if he modified the cache_dirs script in any way.

 

Looking at the checksum I presume not... 

 

Sorry Joe L. if this ends up being a GUI issue...

I don't think it is modified, as the md5sum is identical.    I just wanted to make sure it was not possibly evaluating quotes as it was being extracted and changing the resulting logic. (and the md5sum shows it is not)

 

As far as needing both the quotes and the backslash, well. there is a lot of logic in the script attempting to help you invoke the script correctly.  It appears the logic validating the directory names is expecting to not see spaces in share names.

The last few times I've run

find -name '*searchterm*'

, most disks are spinning up. I don't recall this happening previously. Any guesses on the cause?

syslog-2013-03-01.txt

The last few times I've run

find -name '*searchterm*'

, most disks are spinning up. I don't recall this happening previously. Any guesses on the cause?

 

Just a guess, cachedir isn't caching deep enough into your folders? Say you tell it to cache 4 deep and you have a folder tree like:-

 

\Disk1\A\b\c\d\e\f

 

Cachedirs will only scan up to D, so, when 'find' looks in /e and /e/f it'll have to spin up the drives.

Or not... I have been using cache dirs and I have noticed that when I disable it my disks are more spun down then when it is enabled.... I am trying several routes to try and understand, this because the base behind cache_dirs is sound and -should- work. So something else is going on that is causing an adverse effect.

 

Joe: Cache_Dirs -basically- (extremely oversimplified) does repeated drive dir listings to make sure those listings are kept in memory.

 

Now suppose you are in a situation where memory is extremely overstressed, could that cause cache dirs to actually keep the disks spun UP because the actions cache_dirs is taking are actually causing disk spinup ?

The last few times I've run

find -name '*searchterm*'

, most disks are spinning up. I don't recall this happening previously. Any guesses on the cause?

 

Just a guess, cachedir isn't caching deep enough into your folders? Say you tell it to cache 4 deep and you have a folder tree like:-

 

\Disk1\A\b\c\d\e\f

 

Cachedirs will only scan up to D, so, when 'find' looks in /e and /e/f it'll have to spin up the drives.

 

It appears as though I have some dirs that are seven deep: /boot/cache_dirs -d 5 -m 3 -M 5 -w is now /boot/cache_dirs -d 5 -m 3 -M 5 -e "Backup" -e "Pics" -w

 

I'm going to add an ignore command for those. They're just backups anyway.

If I don't export disk shares and only use user shares, I need to the "-u" argument for this to work properly, right?

  • Author

If I don't export disk shares and only use user shares, I need to the "-u" argument for this to work properly, right?

I never use the -u option personally, since user-shares are already (and only in) memory.  They do not exist physically on a disk.  Their actual disk blocks are on the physical disks.  User-shares are basically pointers to the actual disk shares. 

 

The -u option was added so you can experiment.  It might help, it might not, but in the end it is a request for a specific block from the physical disk you are trying to avoid if it is already been cached.

 

Let us know how it works for you.  As I said, I never use it. 

 

Joe L.

cache_dirs crashes for me all the time. If I have a putty telnet prompt open I can see this:

 

root@Tower:/boot# cache_dirs -w
cache_dirs process ID 5122 started, To terminate it, type: cache_dirs -q
root@Tower:/boot# ./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: subst.c:7606: cannot allocate 112 bytes (901120 bytes allocated)
./cache_dirs: xmalloc: execute_cmd.c:3599: cannot allocate 72 bytes (901120 bytes allocated)
./cache_dirs: line 462: [: : integer expression expected
./cache_dirs: xmalloc: stringlib.c:135: cannot allocate 120 bytes (901120 bytes allocated)

I guess cache_dirs is crashing because it doesn't have enough memory. I have 4Gb of ram.

 

I have also tried to start cache_dirs with only my movies and tv share, like this:

 

cache_dirs -m 3 -M 5 -d 3 -i "Movies" -i "TV\ Series" -w

But cache_dirs crashes within a couple of hours. My movie share is 7.58Tb and consist of ~1 190 movies with nfo, md5, folder.jpg, backdrop.jpg files in every folder. And my TV share is 10.01Tb and consist of ~7 397 episodes and the shares is spread across 11 disks.

 

So at least it's ~ (1 190 x 5) + 7 397 = 13 347 files. And some movies and episodes is dvd backups like several *.vob *.ifo *.bup files. So my guess would be it's closer to 15 000 files that cache_dirs need to scan.

 

Plugins that I run is Subsonic and unmenu.

 

Is there anything I can try, so cache_dirs doesn't crash on me?

  • Author

what does

free -l

and

ulimit -a

and

ps -eo size,pid,user,command | sort -n

show while the errors are occurring?

 

The last "ps" command will show where your memory is being used by processes. 

 

Joe L.

 

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.