enmesh-parisian-latest

Yes over the last few days I've deleted the docker file about 6-7 times to keep the media server up and running. It's clear now that it's not fixing the issue, so I just stop & start all containers to temporarily fix the issue. Edit: I've noticed that the problem occurs more quickly if beets is importing music from the download folder, is it possible the beets config files are corrupted, or something to do with the media itself?

Hey so I've made all the suggested changes however docker is still crapping itself after a few hours. There's no appdata or system files outside cache, so I'm assuming there's a corrupted settings file somewhere which is still causing issues, any idea how I can identify the source? The attached diagnostics file was exported a few mins after docker crapped itself. At the time the most intensive action was a beets import of music in the "media" share, I could tell something had happened when the plex music stream cut out. I've found I can temporarily fix the issue by stopping and starting all containers, no need to delete the docker.img. On side note, the Unraid terminal wouldn't load this morning until I restarted the machine, I had the same issue as this guy: Machine hung for ~45mins during reboot, needed to hold the power button down to get a power cycle. There's something amiss with the system. tobor-server-diagnostics-20180817-1418.zip

Having same issue. Problems with docker & containers too if that helps

Yes, thanks for the link, it's really helpful. I'll slowly add the offending containers and see how I go.

Thanks very much for clarifying, I had "read" the link but I incorrectly though I understood the cache setting so somehow skimmed over all the info I needed to read. The "prefer" setting is now set for both shares. I'll re-read the link and try what you've suggested. There's still something wrong, however I expect it can be fixed once shares can write back to the cache.

Thanks very much for checking, As per your recommendations: - I've disabled cache for all shares except "system" and "appdata"which are now set to "yes". - I've added appropriate min-free amounts to all shares. - I've reduced data on some of the fullest disks using unbalance However I still have a mystery issue causing the docker image to seize up. Is there some way I can identify what's causing the problem?

Yes you're right, it's set currently to 2,000,000. There's certainly something seriously wrong still. After disabling cache for "media" and deleting docker.img several times today, the unraid docker tab is very sluggish to load and docker containers are very slow to load if they load at all (most don't). I'd really appreciate if someone with some more experience than myself could take a quick look at my diagnostics, I've spent a few days trying to work this out without any results so far. EDIT: After more troubleshooting, I think there may've been a corrupted file created by deluge. I've deleted the last few days of deluge data and nuked the appdata. EDIT 2: Was working for a while but nope, using Krusader and triggered something. Like day and night, suddenly all containers are lagging, can't refresh. The exact use which triggered the behaviour (after 2 hours of perfect use) was; open krusader tab > navigate to a "media/downloads" share bookmark, no response, all containers now unresponsive, unraids docker page now takes ~20 secs to load (usually instant). I stopped containers, deleted docker image, started docker and loaded plex again, now running smoothly again. Can someone shed some light on what's wrong here? tobor-server-diagnostics-20180816-1848.zip

I assume I need to stop the array to access this setting? I can't see it in the cache drive settings... EDIT: Stopped array but no setting ?

That's probably a good solution for my paltry 128GB cache, however: • downloads are much much faster when using cache • typically a movie/tv will get watched shortly after downloading, so having it on cache is pretty neat. • uploading to the swarm is much quicker while downloading to cache I'd also like to get an idea of how things are working under the hood so I have a better idea of how to plan any upgrades.

Thanks for your reply. That may be the issue, however you mention "min free space for the cache drive", my understanding is the min free space is set for each share. docker.img is in the "system" share which has 0KB min free space "media" share has about 20GB min free space. "appdata" doesn't get much of a workout, but that's also on 0KB

Hey, I have a newish setup with 2 x 128GB SSDs (mirrored) as cache drives. It's clearly not enough for my daily usage as the drives are regularly filling resulting in a corrupted docker image. Mover is trying to keep up but every couple of days the server will be super busy and the cache will fill up. Short of buying more cache drives, is there a way I can protect the docker image from a full cache drive, or at least make mover a little more efficient? I've attached my diagnostics and a screenshot of my mover settings. Thanks tobor-server-diagnostics-20180816-1113.zip

So I ran out of space on the server, seems like mover was trying to copy about 4TB of data for some reason, I killed mover with: p:kill mover Then did a clean reboot, turned off cache for the offending media folder, deleted all the new copied files, cleaned up the original directory (mover had ruined a few files somehow), then enabled cache for the media folder again, ran mover, and now it's all cleared up. Lesson learned is not to do any large data moves without turning off cache first.

So I made a bit of a mistake last night, I was trying to clear up about 300 torrents in Deluge and move them to Rutorrent (deluge was making too many mistakes). So I went into the Krusader container and moved all the files from the deluge download folder to the rutorrent folder, something was clearly wrong with the move, rutorrent was failing file checks and generally being a dick. I decided I'd stop all the docker containers and launch one by one, but they wouldn't shut down. I checked the logs and saw mover was transferring the files one by one off the 120GB cache drive. I figured I'd leave it overnight to sort itself out, but now the array in 99% full and mover is still running. I should note, all the files in deluge were hard linked, I had 2.8TB free yesterday, now I have 800GB. All containers are now stopped but the cache is still showing something writing to it, what's going on!? tobor-server-diagnostics-20180727-1236.zip

Does is make a difference that the drive disappeared from the array shortly after I noticed this? I shut down, checked cables and booted up again, disk is back but I'm concerned something may be amiss.

I'm no expert but something seems wrong here: Reads: 334,415 Writes: 18,446,744,073,709,549,568 tobor-server-diagnostics-20180726-1014.zip

Any ideas?

Hey, I've been running into an issue in the last week where whenever Radarr sends a large number of torrents to Deluge, Deluge locks up and cannot be accessed without a container restart. Looking at the my-netdata container, I can see Used Memory without Cache climbing until the Memory reaches a max value of 1.1855 GB. I have 32 GB of RAM installed, and deluge only has about 300 torrents loaded, so what's going on? Where does the 1.1855 Gb number come from? tobor-server-diagnostics-20180720-1212.zip

Bump

Bump, anyone?

Bump, anyone?

Hey, I have a new build and am desperately trying to set up reliable hard linking with radarr & deluge. I've hit a wall, see below • Radar and deluge have access to the same share containing both the download folder & the movie folder, eg: Radarr host path: /media : /mnt/user/media/ Radarr movie root folder: /media/movies/ Deluge host path: /media : /mnt/user/media/ Deluge move complete downloads: /media/downloads/passthepopcorn/ • Radarr is set up to hard link the files to the movie root (/media/movies/). • In the case of a test file I added to Radarr, "Spider Man 3" the shares folder indicates both the download file and Radarrs supposedly hard linked version both reside on the same disk, in this case the cache drive (see attached screenshots). This is where I'm stuck; • When checking the Inode of the two files, both indicate they are linked twice, but they have different Inodes?! The downloaded file: root@server:/mnt/user/media/downloads/passthepopcorn# stat Spider-Man.3.2007.1080p.BluRay.DTS.x264.D-Z0N3.mkv | grep Inode Device: 21h/33d Inode: 10645 Links: 2 Radarrs movie foot file: root@server:/mnt/user/media/movies/Spider-Man 3 (2007)# stat Spider-Man\ 3\ \(2007\)\ Bluray-1080p.mkv | grep Inode Device: 21h/33d Inode: 15657 Links: 2 Can someone shed some light on this please? As a followup query, if the mover moves the files off the cache drive, will that break the hard links (assuming they worked in the first place)? server-diagnostics-20180711-1158.zip

Ok I think I figured it out, I had the SSD filesystem set up as "auto", changing it to btrfs seems to have solved the problem. Thanks for the replies

Hey, I'm new to unraid and pc building in general. I picked up an Adaptec RAID 71605 card with 4 x mini SAS HD ports. I'm sitting in the Adaptec RAID Configuration Utility trying to work out if I should be in "HBA" or "Simple Volume" mode. Options are: With 4 x SATA ports to each mini SAS HD port, I'm looking at 16 drives. Is there going to be a bottleneck issue plugged into one PCI-3 slot? Any other settings I should be on the lookout for while setting up the card? Thanks!

Any suggestions after viewing the diagnostics?

Oh right sorry, that was certainly the wrong file. Sorry. tobor-server-diagnostics-20180701-2213.zip