sambo Posted February 9, 2013 Share Posted February 9, 2013 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 Quote Link to comment
sambo Posted February 10, 2013 Share Posted February 10, 2013 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? Quote Link to comment
Joe L. Posted February 10, 2013 Author Share Posted February 10, 2013 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. Quote Link to comment
Joe L. Posted February 10, 2013 Author Share Posted February 10, 2013 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. Quote Link to comment
sambo Posted February 10, 2013 Share Posted February 10, 2013 True, nice point Joe. I renamed script, will see if disk still spinup, if yes will try to run inotifywatch Quote Link to comment
settings Posted February 18, 2013 Share Posted February 18, 2013 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 Quote Link to comment
Joe L. Posted February 18, 2013 Author Share Posted February 18, 2013 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. Quote Link to comment
Helmonder Posted February 19, 2013 Share Posted February 19, 2013 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 ? Quote Link to comment
Joe L. Posted February 19, 2013 Author Share Posted February 19, 2013 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. Quote Link to comment
Helmonder Posted February 19, 2013 Share Posted February 19, 2013 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. Quote Link to comment
mrow Posted February 26, 2013 Share Posted February 26, 2013 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/ Quote Link to comment
Joe L. Posted February 26, 2013 Author Share Posted February 26, 2013 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 Quote Link to comment
mrow Posted February 26, 2013 Share Posted February 26, 2013 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.. Quote Link to comment
speeding_ant Posted February 26, 2013 Share Posted February 26, 2013 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... Quote Link to comment
mrow Posted February 26, 2013 Share Posted February 26, 2013 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. Quote Link to comment
speeding_ant Posted February 26, 2013 Share Posted February 26, 2013 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 Quote Link to comment
Joe L. Posted February 26, 2013 Author Share Posted February 26, 2013 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. Quote Link to comment
jeff.lebowski Posted March 1, 2013 Share Posted March 1, 2013 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 Quote Link to comment
Automatic Posted March 1, 2013 Share Posted March 1, 2013 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. Quote Link to comment
Helmonder Posted March 1, 2013 Share Posted March 1, 2013 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 ? Quote Link to comment
jeff.lebowski Posted March 1, 2013 Share Posted March 1, 2013 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. Quote Link to comment
Smitty2k1 Posted March 2, 2013 Share Posted March 2, 2013 If I don't export disk shares and only use user shares, I need to the "-u" argument for this to work properly, right? Quote Link to comment
Joe L. Posted March 2, 2013 Author Share Posted March 2, 2013 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. Quote Link to comment
Hogwind Posted March 9, 2013 Share Posted March 9, 2013 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? Quote Link to comment
Joe L. Posted March 9, 2013 Author Share Posted March 9, 2013 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. Quote Link to comment
Recommended Posts
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.