Necrotic

I think I have 4+ shucked drives, all of them running for multiple years. No issues on my end. Most are either WD Red, or the white labeled ones that are basically Red drives. I don't think shucked drives change the lifetime, for that you may want to look at the backblaze report on their failure rates. Some are just more prone that others (apparently WD were higher than average) but keep in mind they use those in datacenters so usage is more intense. Personally, for the price I am ok with the slightly higher risk and havent had any issues.

Background The new sata spec changed the way the 3rd pin worked, it now disables the drive if it gets a 3.3v signal. This was intended for datacenter use and usually isn't relevant for consumer drives at this time. However there have been a lot of people buying external drives and taking them out of the enclosure (shucking) as the prices are much better. Now for years the solution is usually to either add tape over the pin, remove the pin, modify the 3.3v power from the cable, use a molex to sata (since molex doesnt carry 3.3v), etc. They each have downsides. My main point Its driving me nuts that no one had just made an adapter that goes at the end of the sata power cable and simply removes that 3rd pin connection. Has anyone found something like this? from a reliable source? Its the simplest solution out there and so obvious but I cant seem to see anyone that has done it.

@SlrG Thanks! I have updated the original post back to the .cnf file.

Edit: Nvm, this seems to be a symptom of a much larger problem. None of my shares are showing, restarting the array didnt fix it and it fails to load all dockers. Im taking this to normal unraid support. Edit2: Ended up restarting the system and that fixed it. It was weird, I hope this isn't a symptom of a larger issue. Guys, I checked today my calendar on Sonarr and it wouldn't load. I tried restarting the docker but I get an "execution error". Any idea? Checking the unraid log I find the following: May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered blocking state May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered disabled state May 18 10:14:09 unRAID kernel: device vethba3921d entered promiscuous mode May 18 10:14:09 unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): vethba3921d: link is not ready May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered blocking state May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered forwarding state May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered disabled state May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered disabled state May 18 10:14:09 unRAID kernel: device vethba3921d left promiscuous mode May 18 10:14:09 unRAID kernel: docker0: port 9(vethba3921d) entered disabled state unraid-diagnostics-20190518-1016.zip

Was it completely gone from the settings or was it listed and just not working correctly?

Thanks for the update niwmik, please let me know how it proceeds from here.

So I stopped it last night, changed it from adaptive to fixed. Started the plugin again. I arrived this afternoon and find one core pegged at 100% once more. The log stops at 5:58am. I guess I will have to disable this until a solution can be found, I will try to update unraid at some point and see if that resolves it or perhaps find a way to roll to an earlier version of cache_dirs.

So I had updated the plugin after my last post (now running versions 2.2.5/2018.11.18 on unraid 6.5.2) but I didn't reboot unraid. I was gone for a couple of days, come back and its pegged to 100% again on one of my cores. I haven't restarted the process this time, and I will leave it as such in case you have further commands for me to run. I followed Fireballs post, here are the commands I have seen Alex request he runs with my output (along also with top). The cache_dirs.log file seems to be empty but there are two others I found in there with some data. I am unsure why it ends this morning at 3:41am and there doesn't seem to be anything on the var/log/cache_dirs.log unless its being saved somewhere else and I just need to check tomorrow (Update: So I checked, it didn't create a new file which leads me to believe that its hung). PS. All my drives excluding the parity are currently spun up. Unsure if its related to this or not, or maybe its emby doing its scans running up the drives as the cache might not be working. pstree -p | grep -2 cache_dirs |-avahi-daemon(4185)---avahi-daemon(4186) |-avahi-dnsconfd(4195) |-cache_dirs(9820)---cache_dirs(3574)---cache_dirs(3575)---mdcmd(3576) |-crond(1602) |-dbus-daemon(1538) ps -e x -o ppid -o pid -o pgid -o tty -o vsz -o rss -o eti me -o cputime -o rgroup -o ni -o fname -o args | grep "cache_dirs\|find\|wc" 9820 3574 4591 ? 14416 3204 16:19:06 00:00:00 root 0 cache_ di /bin/bash /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/cache_dirs -e .FTP -e Backup -e CAAppdataBackup -e appdata -e system -l on 3574 3575 4591 ? 14416 3208 16:19:06 16:19:05 root 0 cache_ di /bin/bash /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/cache_dirs -e .FTP -e Backup -e CAAppdataBackup -e appdata -e system -l on 1 9820 4591 ? 14416 4168 3-01:00:46 00:03:16 root 0 cache_ di /bin/bash /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/cache_dirs -e .FTP -e Backup -e CAAppdataBackup -e appdata -e system -l on 29926 30702 30701 pts/0 9812 2068 00:00 00:00:00 root 0 grep grep cache_dirs\|find\|wc? top - 20:16:35 up 162 days, 22:45, 1 user, load average: 1.05, 1.07, 1.07 Tasks: 346 total, 2 running, 236 sleeping, 0 stopped, 1 zombie %Cpu(s): 25.9 us, 0.7 sy, 0.0 ni, 73.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16113940 total, 5576676 free, 7793844 used, 2743420 buff/cache KiB Swap: 0 total, 0 free, 0 used. 6645500 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3575 root 20 0 14416 3208 1496 R 100.0 0.0 995:13.86 cache_dirs 17977 nobody 20 0 2299916 181864 4132 S 2.7 1.1 415:15.15 sabnzbdplus 31464 root 20 0 572708 35896 1972 S 2.0 0.2 364:10.26 cadvisor 4208 root 20 0 294864 3232 2524 S 0.3 0.0 878:32.51 emhttpd 4730 root 20 0 1395280 89652 824 S 0.3 0.6 1295:37 shfs 5543 root 20 0 2237536 58188 28128 S 0.3 0.4 265:50.77 dockerd 25051 nobody 20 0 174252 31572 1948 S 0.3 0.2 4:21.81 python 28802 daemon 20 0 4818076 341044 10692 S 0.3 2.1 737:11.89 EmbyServer 1 root 20 0 4504 772 712 S 0.0 0.0 1:17.76 init 2 root 20 0 0 0 0 S 0.0 0.0 0:01.28 kthreadd 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 7 root 20 0 0 0 0 S 0.0 0.0 13:37.10 ksoftirqd/0 8 root 20 0 0 0 0 I 0.0 0.0 205:33.34 rcu_preempt 9 root 20 0 0 0 0 I 0.0 0.0 0:08.05 rcu_sched 10 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh 11 root rt 0 0 0 0 S 0.0 0.0 0:21.45 migration/0 12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 14 root rt 0 0 0 0 S 0.0 0.0 0:21.40 migration/1 15 root 20 0 0 0 0 S 0.0 0.0 10:54.18 ksoftirqd/1 17 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H 18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2 19 root rt 0 0 0 0 S 0.0 0.0 0:21.53 migration/2 20 root 20 0 0 0 0 S 0.0 0.0 11:02.52 ksoftirqd/2 22 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H 23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3 24 root rt 0 0 0 0 S 0.0 0.0 0:21.31 migration/3 25 root 20 0 0 0 0 S 0.0 0.0 9:42.75 ksoftirqd/3 27 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H 28 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 29 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns 291 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper 292 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback cache_dirs-20181207_1544175601.log cache_dirs.log cache_dirs-20181206_1544089201.log

Yeah, I did go ahead and updated but as I indicated, its been a long running issue across multiple versions. Did you guys "Turn it OFF and ON again" (aka reboot)? The issue has persisted across multiple reboots.

So I am running the dynamix version (currently have 2.2.0j on unraid 6.5.2). But I have been having a recurring problem across a few versions now. I will get back to my server, and find one core running at 100% constantly. Its always cache_dirs that is doing this. I would disable it, then enable again and it would start working right again. It used to happen maybe once a month, now it seems to be happening like every other day. I am uploading my settings, I excluded my appdata and docker system folder based on some feedback a while back. Any idea what is up?

For those of you having issues with crashes, I highly advise you seek support at the Emby forums. They don't really monitor this thread much from what I have seen, but you can get excelent support at theirs. Here is the thread specific for the docker: https://emby.media/community/index.php?/topic/9754-docker/

This seems like something that could be done thru a plugin

No I mean I get that spam without running pre-clear. Its just constantly adding to my log all the time.

Hi everyone, for some reason pre-clear is using up most of my log space. Has anyone experienced this? PS. I'm running version 6.3.5. Not updated yet since I wasn't so confident on stability and such. root@unRAID:~# df -h /var/log Filesystem Size Used Avail Use% Mounted on tmpfs 384M 356M 29M 93% /var/log root@unRAID:~# du -sm /var/log/* 1 /var/log/PhAzE-Logs 1 /var/log/apcupsd.events 1 /var/log/apcupsd.events.1 1 /var/log/apcupsd.events.2 1 /var/log/apcupsd.events.3 1 /var/log/apcupsd.events.4 0 /var/log/btmp 0 /var/log/btmp.1 0 /var/log/cron 0 /var/log/debug 1 /var/log/dmesg 2 /var/log/docker.log 1 /var/log/faillog 1 /var/log/lastlog 0 /var/log/libvirt 0 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 3 /var/log/packages 0 /var/log/plugins 351 /var/log/preclear.disk.log 1 /var/log/removed_packages 1 /var/log/removed_scripts 0 /var/log/samba 1 /var/log/scripts 0 /var/log/secure 0 /var/log/setup 0 /var/log/spooler 1 /var/log/syslog 2 /var/log/syslog.1 1 /var/log/wtmp This is what I can see when I do a tail, its adding it every 10 seconds or something: Thu Apr 5 17:51:32 EDT 2018: get_content Finished: 0 Thu Apr 5 17:51:43 EDT 2018: Starting get_content: 0 Thu Apr 5 17:51:43 EDT 2018: Disks: + /dev/sdd => /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T2574503 + /dev/sdc => /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T2277054 + /dev/sdb => /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T2737524 + /dev/sdf => /dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX11DC57SFX7 + /dev/sdg => /dev/disk/by-id/ata-WDC_WD50EFRX-68L0BN1_WD-WXB1HB4KUF1J + /dev/sde => /dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N0303087 + /dev/sdh => /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S21NNXBGA75793K + /dev/sda => /dev/disk/by-id/usb-Kingston_DT_Micro_1C6F654E4910BD30C95403FF-0:0 Thu Apr 5 17:51:43 EDT 2018: unRAID Serials: + 0951-168A-4910-BD30C95403FF + WDC_WD60EFRX-68L0BN1_WD-WX11DC57SFX7 + WDC_WD30EFRX-68AX9N0_WD-WMC1T2277054 + WDC_WD30EFRX-68AX9N0_WD-WMC1T2574503 + WDC_WD30EFRX-68EUZN0_WD-WCC4N0303087 + WDC_WD30EFRX-68AX9N0_WD-WMC1T2737524 + WDC_WD50EFRX-68L0BN1_WD-WXB1HB4KUF1J + Samsung_SSD_850_EVO_250GB_S21NNXBGA75793K + Kingston_DT_Micro_1C6F654E4910BD30C95403FF-0:0 Thu Apr 5 17:51:43 EDT 2018: unRAID Disks: + /dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX11DC57SFX7 + /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T2277054 + /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T2574503 + /dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N0303087 + /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T2737524 + /dev/disk/by-id/ata-WDC_WD50EFRX-68L0BN1_WD-WXB1HB4KUF1J + /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S21NNXBGA75793K + /dev/disk/by-id/usb-Kingston_DT_Micro_1C6F654E4910BD30C95403FF-0:0 Thu Apr 5 17:51:43 EDT 2018: benchmark: get_unasigned_disks() took 0.004354s. Thu Apr 5 17:51:43 EDT 2018: benchmark: get_all_disks_info() took 0.004442s.

Did anyone else have issues with cachedirs going nuts and pegging one cpu to 100% forever? It happens rarely but over the past year or something had it happen twice. I went into settings, disabled it and re-enabled and it fixed it.

Thanks. I got the following: Done, had to relocate 11 out of 235 chunks The cache now says: Data, single: total=220.01GiB, used=68.10GiB System, single: total=4.00MiB, used=48.00KiB Metadata, single: total=2.01GiB, used=619.44MiB GlobalReserve, single: total=285.98MiB, used=0.00B Now the big question is, how do I get it back to xfs without messing everything up?

Well shoot, I think this is what it did automatically. I am in the wrong place then for this post then...Do you think I should go and repost, if so where? I did manage to go in and wipe the recycle bin, that cleared some space and seemed to give me some breathing room.

Edited my post. Seems like my entire system just went on the fritz....

Yes, which diagnostics in particular? the SMART report? If so here it is: Samsung_SSD_850_EVO_250GB_S21NNXBGA75793K-20171216-0155.txt Edit: Just in case here is the unraid one: unraid-diagnostics-20171216-0158.zip

I am having some problems with this docker. All of the sudden I am getting the following error on the dashboard: "Too little diskspace forcing PAUSE" Both the incomplete and complete folders are bound to my cache drive, which has 100GB+ of free space yet its happening all the time now. I was able to force it to finish a download by pausing and unpausing multiple times, but its not happening all over. Below is the section in the code where it pauses. 2017-12-15 19:56:17,177::INFO::[directunpacker:265] DirectUnpacked volume 33 for aBtwz76srBc3AATP 2017-12-15 19:56:23,205::WARNING::[assembler:77] Too little diskspace forcing PAUSE 2017-12-15 19:56:23,205::INFO::[downloader:277] Pausing 2017-12-15 19:56:23,205::INFO::[directunpacker:445] Aborting all DirectUnpackers 2017-12-15 19:56:23,205::INFO::[directunpacker:372] Aborting DirectUnpack for aBtwz76srBc3AATP Does anyone have suggestions about what is going on? sabnzbd (2).log

Thanks, I got home and removed the ram each one and blew it for possible dusting. I am running a Memtest right now and will see how it goes. If there is no error, how do I recover my docker? Should I just manually run that first command in the command line? Otherwise they don't show in my list.

Guys, I got the error below while trying to update the docker and the docker dropped from the list. Is this something specific to my computer? I recently upgraded the CPU and Ram, and I didn't have any issues at the time but I figured best to let you know. root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="sabnzbd" --net="bridge" -e TZ="America/New_York" -e HOST_OS="unRAID" -e "PUID"="99" -e "PGID"="100" -p 8080:8080/tcp -p 9090:9090/tcp -v "/mnt/user/appdata/downloads":"/downloads":rw -v "/mnt/user/appdata/apps/sabnzbd/incomplete-downloads":"/incomplete-downloads":rw -v "/mnt/user/appdata/apps/sabnzbd":"/config":rw linuxserver/sabnzbd unexpected fault address 0x1502b10 fatal error: fault [signal SIGSEGV: segmentation violation code=0x1 addr=0x1502b10 pc=0x93101d] goroutine 1 [running, locked to thread]: runtime.throw(0xa8029d, 0x5) /usr/lib64/go1.7.4/go/src/runtime/panic.go:566 +0x95 fp=0xc4200e3ce8 sp=0xc4200e3cc8 runtime.sigpanic() /usr/lib64/go1.7.4/go/src/runtime/sigpanic_unix.go:27 +0x288 fp=0xc4200e3d40 sp=0xc4200e3ce8 html.init() /usr/lib64/go1.7.4/go/src/html/entity.go:2208 +0x11fd fp=0xc4200e3da0 sp=0xc4200e3d40 html/template.init() /usr/lib64/go1.7.4/go/src/html/template/url.go:106 +0x6d fp=0xc4200e3e28 sp=0xc4200e3da0 golang.org/x/net/trace.init() /tmp/SBo/docker-1.12.6/vendor/src/golang.org/x/net/trace/trace.go:1071 +0x53 fp=0xc4200e3e60 sp=0xc4200e3e28 google.golang.org/grpc.init() /tmp/SBo/docker-1.12.6/vendor/src/google.golang.org/grpc/trace.go:121 +0x62 fp=0xc4200e3e90 sp=0xc4200e3e60 github.com/docker/docker/api/server/httputils.init() /tmp/SBo/docker-1.12.6/.gopath/src/github.com/docker/docker/api/server/httputils/httputils.go:107 +0x56 fp=0xc4200e3e98 sp=0xc4200e3e90 github.com/docker/docker/dockerversion.init() /tmp/SBo/docker-1.12.6/.gopath/src/github.com/docker/docker/dockerversion/version_autogen.go:15 +0x38 fp=0xc4200e3ea0 sp=0xc4200e3e98 github.com/docker/docker/api/client.init() /tmp/SBo/docker-1.12.6/.gopath/src/github.com/docker/docker/api/client/utils.go:191 +0x7b fp=0xc4200e3ee0 sp=0xc4200e3ea0 main.init() /tmp/SBo/docker-1.12.6/cmd/docker/usage.go:23 +0x67 fp=0xc4200e3f38 sp=0xc4200e3ee0 runtime.main() /usr/lib64/go1.7.4/go/src/runtime/proc.go:172 +0x1bf fp=0xc4200e3f90 sp=0xc4200e3f38 runtime.goexit() /usr/lib64/go1.7.4/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc4200e3f98 sp=0xc4200e3f90 goroutine 17 [syscall, locked to thread]: runtime.goexit() /usr/lib64/go1.7.4/go/src/runtime/asm_amd64.s:2086 +0x1 The command failed.

Oh thanks. In the old version that number used to be the amount in the trash bin itself. I didn't want to wipe 53GB of stuff by mistake.

Dlandon, I was running 6.2.4 with your previous recycle bin. I wanted to update unraid to newest version 6.3.2, I emptied the recycle bin before I started but I forgot to uninstall before the update. I updated unraid, started the array, uninstalled the old plugin, searched for the new one on CA and installed it. When I go into the settings for it it shows me it has 53G in the recycle bin, I am worried that it may be including everything in my cache drive in it or something. I have disabled it for now, could you advise what I can do to figure out what went wrong and fix it? Thanks!

Guys, I transitioned from Phaze plugin to this docker and was able to keep all my settings. See below the process I followed. I am still testing but seems to be working ok.