alturismo

after some tests with disabling cache_dir plugin i can confirm its back to normal again. What i didnt test yet is a reboot without cache_dir plugin (uninstall, reboot, check ...), only disabled now ... as there where no changes still a myst what made this happen

urgs, sorry, yes i do ...

hi, may an idea about Filebot error, i guess since 664 (happened last nite, updated today to 665, same behavior) from log Use excludes: /config/amc-exclude-list.txt (1) Ignore hidden: /media/Temp/.keep # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000014d6dad1aa72, pid=243, tid=0x000014d712366700 # # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build 1.8.0_161-b12) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libmediainfo.so.0+0x3c3a72] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /tmp/hs_err_pid243.log i attached the error log in case its useful, i use filebot without GUI as note (config GUI no) for an tip, thanks ahead hs_err_pid243.log

the reboot was only once required after changing the "broken" script. since then i didnt had to reboot on changes etc ... i think you can follow this in logs, i started this plugin manually after update to 664 this morning, when u see all lines (not only the 1 line) you should be good, also here the disks spin down automatically after the timeout (here 15 mins) they spinned up by activating the plugin and then ... as it should be, perfect

i also had alot of disk spinups since latest unraid releases, so i came to this plugin and now its perfect here. my settings are Nov 5 06:34:38 AlsServer cache_dirs: Stopping cache_dirs process 27693 Nov 5 06:34:39 AlsServer cache_dirs: cache_dirs service rc.cachedirs: Stopped Nov 5 06:34:39 AlsServer cache_dirs: Arguments=-i Daten -i Media -i Temp -X 300 -Y 120 -p 0 -u -U 0 -l off -D 9999 Nov 5 06:34:39 AlsServer cache_dirs: Max Scan Secs=10, Min Scan Secs=1 Nov 5 06:34:39 AlsServer cache_dirs: Scan Type=fixed Nov 5 06:34:39 AlsServer cache_dirs: Max Scan Depth=none Nov 5 06:34:39 AlsServer cache_dirs: Use Command='find -noleaf' Nov 5 06:34:39 AlsServer cache_dirs: ---------- Caching Directories --------------- Nov 5 06:34:39 AlsServer cache_dirs: Daten Nov 5 06:34:39 AlsServer cache_dirs: Media Nov 5 06:34:39 AlsServer cache_dirs: Temp Nov 5 06:34:39 AlsServer cache_dirs: ---------------------------------------------- Nov 5 06:34:39 AlsServer cache_dirs: Setting Included dirs: Daten,Media,Temp Nov 5 06:34:39 AlsServer cache_dirs: Setting Excluded dirs: Nov 5 06:34:39 AlsServer cache_dirs: min_disk_idle_before_restarting_scan_sec=60 Nov 5 06:34:39 AlsServer cache_dirs: scan_timeout_sec_idle=300 Nov 5 06:34:39 AlsServer cache_dirs: scan_timeout_sec_busy=120 Nov 5 06:34:39 AlsServer cache_dirs: scan_timeout_sec_stable=30 Nov 5 06:34:39 AlsServer cache_dirs: frequency_of_full_depth_scan_sec=604800 Nov 5 06:34:39 AlsServer cache_dirs: Including /mnt/user in scan Nov 5 06:34:39 AlsServer cache_dirs: cache_dirs service rc.cachedirs: Started: '/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/cache_dirs -i "Daten" -i "Media" -i "Temp" -X 300 -Y 120 -p 0 -u -U 0 -l off -D 9999 2>/dev/null' like this i have 0 spinups left ... may a try, specially cache pressre 0 helped ...

after 2 days usage with plugin cache_dir and pressure 0 im there where i can say its normal like before ... drives only come up when they should, no more spinups by laptop booting, no more spinups by access media files from cache ... like it was before latest updates ... i hope that this "workaround" wont break other things, but now im good atm. i only have one spinup @ nite ~ 2am without my personal use, but i guess it has something todo with plex, wich was also before latest updates ... so no change here but also doesnt matter. just as note if that may points in the direction what could have changed and causing disk spinups.

after 2 days usage with pressure 0 im there where i was before latest unraid update(s), my drives stay down ... i only have 1 spinup at ~ 2 am, when i have to guess it has something todo with plex server ... nvm. thanks again for this, made my server back to normal behavior as its supposed to be ... i just hope cache pressure 0 will not break something else

may a question about cache pressure setting, i setted now to 0 wich is the maximum when i understand the help correctly. may i ask if this is dangerous for stability, i have ~ 18750 files curently, i have fixed depth min 6 max unlimited. it seems to work better with pressure 0 but i dont want to overact ... i have no idea how much ram is used by this ...

i increeased now the following in the plugin cache_dir, cache pressure 0, ulimit (memory) 0 ... wich also improves the behavior of silent disk usage. may anything to provide wich could be helpful ? could it be the smb 3.1.1 update ? i mean all is running smooth here, just disk behavior changed ... and maybe (just a feeling), when starting media´s in clients, the startup takes longer .... even now when the disks does not all spinup (due cache_dir plugin), like it would take longer to server the data ... from the cache, specially the 1st playback, sample user case, i start a show, it takes about 5 - 10 seconds to startup wich has been faster before when coming from cache ... when i know use /mnt/cache instead the media starts instantly ... same file, same location. i just try to figure where to look for cause, in my eyes i cant find anything what could be the reason, no log or any watch plugin (active streams, file activity, open files) shows a reason why a disk is now starting up ... so in combination with "feeled" access times i think about the access behavior to /mnt/user ... specially on files wich are in physically in /mnt/cache/... so if theres any usercase u need logs, i ll try to provide them, i cant find anything and i dont know how to describe it better

yes it does

ok, some othe tests i made i record tv shows with plex, all files are physically in cache when i now open Avisynth to cut my commercials by just starting webui of avisynth and accessing a folder ALL disks spinup without touching any file, tis happens when using /mnt/user/Media as start folder, and im pretty sure Avisynth also doesnt read all files ... also in this folder there definately no files from ALL disks, usually files are in /cache or /disk4, im ONLY working with the files on /cache, but ALL disks get active ... when i use /mnt/cache/Media im good of course, so i still believe (cause i dunno better) that unraid has some issue when accessing /mnt/user/... to recognize there are cache files, also here im pretty sure that wasnt like this before. and again, NO activity in open files, in active streams or any other log ... so even IF in this case Avysynth would look for the files in the directory im currently in, it shouldnt fire up ALL disks, at least in my understanding of cache and disks ... media access by plex server btw got almost 0 activities now by using the plugin cache_dir with fixed value und pressure 1, so here i have a workaround wich helps alot, but other access is still ... lets say depends on server mood sometimes ok, sometimes just starts all up with no (known) reason.

may its also since the win 10 1809 update ... i just can say its more then before, but why i still guess unraid, open a media file from cache also likes to spinup all drives here meanwhile ... wich also never was like this. client can be kodi on windows, kodi on shield tv, plex on sammy tv, plex from shield tv, plex from web ... looks to me as unraid dunno directly where it really is and searches all disks ... i know this sounds strange ... but im happy it got better with cache_dirs, alot better ... specially the media playback issue

all drives sleeping, then laptop booting up, i log in. then i "hear" my disks are spinning up ... got alot better with cache directories, but not completely solved as i would like to and my shares are all mounted like this, regular network shares in windows ... and im NOT accessing them, i dont even open the file explorer at all, just logging into my win 10 laptop, but as i said, alot better now with cache_dirs and i cant remember its been always like this, im pretty sure it wasnt like this before, cant remember exactly when this behavior changed ... but for me it definately changed, thats why i came to this plugin cause its disturbing me, and i use unraid for ~ 2 years now.

i dont even open the file Explorer ... and as i mentioned, i guess its a unraid issue currently. Gesendet von meinem SM-G950F mit Tapatalk

i dont have any parity and they spinned up when my laptop booted up (where the shares are mounted)

ok, made a safe mode test now started with GUI safe mode, started the array, stopped all dockers, no plugins where running. spinned down the drives so only cache (NVME) and UA (NVME) was active. then started my laptop wich has the shares mounted. 2 of 3 times by only opening the explorer on the smb client the disks starts to spin up ... when it kept calm, entering the network share 1 of 2 will spinup the drives accessing media wich is in /mnt/user/Media/test ... and is physically on the /mnt/cache/Media/test ... will sometimes spinup the drives. so i NEVER executed or touched (opened) any file wich is really on one of my disks (disk 1 - 4). i guess that the smb accesses (even when "sleeping") from clients (VM´s, Dockers, Shield TV, Kodi, ...) are resulting in spinups, even there are no files executed or touched. and even when a file is executed from cache inside the same share where disk files are .. sample /Media/Show/Season1/Episode1.mkv <-- is physically on /server/disk1/Media/Season1/Episode1.mkv /Media/Show/Season1/Episode8.mkv <-- is physically on /server/cache/Media/Season1/Episode8.mkv when i now start Episode8.mkv on an plex client or kodi client, disk1 will most likely spinup ... so unraid (smb) doesnt really know where the file is in 1st case and look in all disks ... wich im pretty sure wasnt like that ... and shouldnt be like that. i think when i browse the shares in the webui from unraid i never get any spinups ... only when i really hit the file and a download or whatever starts then the disk will get spinup, wich is correct. thats just my thoughts. as i never saw any entries in syslog, file activities plugin, open files plugin wich could explain what is happening ... i made a diagnostic from the last test today morning, but i cant see anything, hopefully u can tell what could be the reason ... alsserver-diagnostics-20181101-0756.zip

feedback here, yesterday during the day it seemed to be alot better then before with disk spinups, i could browse shares and almost never had any spinups. now today morning i turned on my laptop, wich has the shares mounted. just by turning the laptop on the disks started to run. this i assume is a current bug in unraid cause its following me since a little while, i hoped i can catch this also with caching. either way, its a huge improvement and thanks for this plugin

urgs, no, of course i have set USE cache, so files stay in cache until mover runs and moves to disks in array, all good, my fault, USE cache, not PREFER

update worked fine, and looking good in 1st views could browse some shares without spinning ... thanks for all the effort

thank you, i attached the diagnostic from latest release, update went fine, no more chmod needed cache_dirs_diagnostics.zip

@Alex R. Berg ok, changed settings now once more, also increased some timings, may my disks are too slow ... Stopping cache_dirs process 12039 cache_dirs version 2.2.2 Setting Memory ulimit to 50000 Setting cache_pressure=1 Arguments=-i Daten -i Media -i Temp -c 6 -X 300 -Y 120 -p 1 -u -l on -D 9999 Max Scan Secs=10, Min Scan Secs=1 Scan Type=fixed Max Scan Depth=none Use Command='find -noleaf' ---------- Caching Directories --------------- Daten Media Temp ---------------------------------------------- Setting Included dirs: Daten,Media,Temp Setting Excluded dirs: min_disk_idle_before_restarting_scan_sec=60 scan_timeout_sec_idle=300 scan_timeout_sec_busy=120 scan_timeout_sec_stable=30 frequency_of_full_depth_scan_sec=604800 Including /mnt/user in scan cache_dirs started 2018.10.31 08:22:35 Executed find in (0s) (disks 0s + user 0s) 00.31s, wavg=00.31s depth 9999 slept 0s Disks idle before/after 311s/311s suc/fail cnt=0/0/0 mode=2 scan_tmo=300s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU= 3%, filecount[9999]=18750 ... is this a working feedback, i cant interprete the log correctly Disks idle before/after 311s/311s <-- idle ok or should be active ? suc/fail cnt=0/0/0 <-- 0 success ? 0 failed ? 0 count ?

ok, 1 st real test today morning after some hours idle, i still get spinning up disks when accessing my shares. i guess my settings aint properly or does adaptive mean theres a learning curve ? i changed now from adaptive to fixed here from my log file now cache_dirs version 2.2.2 Setting Memory ulimit to 50000 Setting cache_pressure=1 Arguments=-i Daten -i Media -i Temp -p 1 -l on -D 9999 Max Scan Secs=10, Min Scan Secs=1 Scan Type=fixed Max Scan Depth=none Use Command='find -noleaf' ---------- Caching Directories --------------- Daten Media Temp ---------------------------------------------- Setting Included dirs: Daten,Media,Temp Setting Excluded dirs: min_disk_idle_before_restarting_scan_sec=60 scan_timeout_sec_idle=150 scan_timeout_sec_busy=30 scan_timeout_sec_stable=30 frequency_of_full_depth_scan_sec=604800 cache_dirs started then there are alot of thos entries ... 2018.10.31 06:55:59 Executed find in (0s) 00.09s, wavg=00.09s depth 9999 slept 0s Disks idle before/after 785s/785s suc/fail cnt=0/0/0 mode=2 scan_tmo=150s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU= 3%, filecount[9999]=18753 2018.10.31 06:56:00 Executed find in (0s) 00.04s, wavg=00.06s depth 9999 slept 1s Disks idle before/after 786s/786s suc/fail cnt=0/0/0 mode=2 scan_tmo=150s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU=17%, filecount[9999]=18753 2018.10.31 06:56:01 Execut..... should this be correct ? i only have 3 shares using the physical disks ... all with the setting to prefer cache (using scheduled mover). all other shares here are cache only anyway.

chmod to 777 changed the status to running root@AlsServer:~# cache_dirs -L ################## PS ####################### PPID PID PGID %CPU %MEM TT VSZ RSS ELAPSED TIME RGROUP NI COMMAND COMMAND 1 15550 7898 0.2 0.0 ? 10312 5476 00:34 00:00:00 root 0 cache_di /bin/bash /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/cache_dirs -i Daten -i Media -i Temp -p 1 -l on 14094 19639 19639 0.0 0.0 pts/1 8964 3348 00:00 00:00:00 root 0 cache_di /bin/bash /usr/local/bin/cache_dirs -L 19639 19641 19639 0.0 0.0 pts/1 8964 2588 00:00 00:00:00 root 0 cache_di /bin/bash /usr/local/bin/cache_dirs -L 19639 19642 19639 0.0 0.0 pts/1 2944 1784 00:00 00:00:00 root 0 tee tee cache_dirs_diagnostics_processes.log 19641 19646 19639 0.0 0.0 pts/1 5712 2028 00:00 00:00:00 root 0 grep grep cache_dirs\|find\|wc ################## PSTREE ####################### |-avahi-daemon(7870)---avahi-daemon(7871) |-avahi-dnsconfd(7880) |-cache_dirs(15550)---sleep(19586) |-crond(1868) |-dbus-daemon(1798) -- | `-smbd-notifyd(1885) |-sshd(7819) |-ttyd(7920)-+-bash(14094)---cache_dirs(19639)-+-cache_dirs(19641)-+-grep(19648) | | | `-pstree(19647) | | `-tee(19642) ################## TOP ####################### top - 22:31:36 up 35 min, 1 user, load average: 0.68, 0.89, 0.97 Tasks: 641 total, 1 running, 638 sleeping, 0 stopped, 2 zombie %Cpu(s): 23.7 us, 8.7 sy, 0.0 ni, 66.7 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st MiB Mem : 32112.6 total, 4553.1 free, 12987.4 used, 14572.1 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 17627.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9658 root 20 0 9326140 8.1g 20528 S 337.5 25.7 22:52.54 qemu-system-x86 1 root 20 0 2444 1616 1512 S 0.0 0.0 0:08.35 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd 7 root 20 0 0 0 0 I 0.0 0.0 0:00.67 kworker/u24:0-btrfs-endio-write 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0.0 0.0 0:00.14 ksoftirqd/0 10 root 20 0 0 0 0 I 0.0 0.0 0:00.80 rcu_sched 11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/0 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 adding: cache_dirs_diagnostics_processes.log (deflated 65%) adding: cache_dirs.log (deflated 91%) adding: syslog (deflated 86%) Generated cache_dirs_diagnostics.zip root@AlsServer:~#

+1 here, i know i had the status "running" before ... and i enabled logs, but there where no logs at /var/log/ i now turned logs off and rebooted server again.

thanks for the info, i start with 2 then now, i guess a update will always require a reboot.