dchamb

Do you think an HBA board is more/less/same performance as on board Sata ports? And can you comment on the existing problems with i915 drivers crashing unRaid 6.9.2?

I currently have an 3rd gen Intel based system with 4 cores and no hyperthreading. Running Plex along with a couple of other Docker apps with >50TB of data using 2 parity drives. Transcoding is the greatest need. So I am looking for an 8 core CPU with 32GB RAM, and a motherboard to support 8 SATA III drives. Also looking to use a 2TB M.2 NVMe for cache. Questions: which CPU brand is better for the application Intel or AMD? Any motherboard recommendations (I've always been an Asus fan but willing to consider others)? Also I want to be able to use unRaid version 6.9.2. I've been stuck on 6.8.3 because I cannot run 6.9.2 on my current configuration. Thanks! Dale

When I tried to move from 6.8.3 to 6.9.2 the server would lock up with no system log. Just could not get it to run more than a few hours before the webgui would freeze and I could not do a clean shutdown. Rolling back to 6.8.3 solved the problem. Several others experienced the same problem. If I understood the problem it had to do with the kernel having compatibility issues with the chipset in the system.

I have an unRaid system running on a Asus P8Z77-V LK with an Intel Core i5-3570 CPU and 32GB RAM with 1TB SSD drive for cache. It's been running fine since 2014 with 4 data disks and 2 parity drives. I am running version 6.8.3 because it has been so solidly reliable and version 6.9.2 would crash with my configuration. Since my hardware is getting long in the tooth, and it could definitely benefit from better CPU performance, I've been considering an upgrade to a newer CPU and motherboard. But it scares me to do so with unRaid since I've never done it before and I have a very large array size (around 48TB). My questions are: 1. What do I need to do to prepare for a transition to a new system? I.e. will the current flash drive containing the unRaid server software need to be changed? Anything I need to do when reconnecting the array drives? 2. Should a new CPU and motherboard eliminate the problems with going to version 6.9.2 or is there a CPU/Motherboard combination I should steer clear of? Thank you for any good advice you could provide. Dale

Not that I've heard. Even when 6.10 comes out I'm waiting to see what others find. I don't have a system to experiment with.

I rolled back to unRaid 6.8.3 and kept my Plex at 125.0.5282-2edd3c44d. Everything is running fine. So if it is something in that version of Plex, it is being triggered by 6.9.2.

Thanks for your thoughts. It helps to have a someone else's perspective. I have a tendency to go overboard lol!

Do you feel a daily backup is unnecessary?

Thanks but I am not finessed enough in Cron to know how to say "run every day at 3am except on the last day of month"

Any thoughts on preventing the backup from starting if a parity check is running?

It's safe. I had to do the same thing since 6.9.2 crashes regularly. 6.8.3 has been rock steady.

Still on 6.8.3 running fine. I invoked the correcting parity check which is now 76.7% complete and has corrected 14637 sync errors. Two CA appdata backup runs have taken place since the parity check started. It looks like both finished successfully. Plex docker is still running. All seems well but I have attached a diagnostic so someone more knowledgeable than me can verify this. I am a bit uneasy about having the CA backup run while a parity check is running, mostly because they are competing for resources. If there is a way to prevent it from running during a parity check, please let me know. I have scheduled a correcting parity check once a month on the last day of the month, and have CA backups run every morning at 3AM. As always I appreciate any input. One other question: is there anything in the diagnostics that could explain why 6.9.2 will not work for my system? Thanks Dale tower-diagnostics-20211202-1009.zip

Spoke too soon. Up to 14,635 sync errors now

I was concerned after so many crashes under 6.9.2 with the uncorrected parity check starting automatically and never completing. When I rolled back to 6.8.3 it came up saying parity was valid. I ran a correcting parity check thinking I'd rather be safe than sorry and it reported 50 sync errors. I hope I haven't screwed something up.

Ok that makes sense. I had shutdown docker while running 6.9.2. That's when I first tried mover but the system eventually crashed. So if I can get mover to put these folders and files on the cache pool while docker is down, the cache pool will be opened and used by the docker apps once docker is reactivated? Will my CA backup use the cache pool as the source and make a copy of it back to the array backup folder?

Just for my clarification regarding the role of parity and the parity check: 1. I have 2 parity drives plus 4 data drives in my array. 2. All disks are functioning normally (no errors). 3. Running parity check so far has reported 50 sync errors corrected. When a sync error is detected and corrected, the only thing modified is the parity, not the data drives, correct? If a sync error is detected, there is no data loss provided my data drives are still fully intact, correct? Thanks Dale

tower-diagnostics-20211127-1421.ziptower-diagnostics-20211127-1510.zip I did find these logs for when I was running 6.9.2. I don't know if they will tell anything about why 6.9.2 was crashing since on the days they were grabbed the system had not crashed yet. But I did find a switch in the appdata backup that allows me to select which docker apps to shutdown during the backup. I am currently running a parity check while the backup is is running and my dockers are still running. Keeping fingers crossed!

Given that my backups are scheduled to start at 3AM daily and the diagnostics were taken around 3:25 PM suggests that the backup failed and did not restart the dockers upon failure. Since this happens only when the parity check is running (at the end of each month), and noting that the backup WILL shutdown the dockers before beginning, could the parity check have interfered with the the backup causing it to fail? If so, how can I set the backup to not start if a parity check is running?

I have encountered the same issue. Running 6.8.3 flawlessly for 462 days. I "upgraded" to 6.9.2 and almost immediately experienced system freezes, slow degradation in connectivity (i.e. webgui not responding, unable to connect via telnet), failure to shutdown the array or the system gracefully, and unable to get diagnostics. After a couple of days I rolled back to 6.8.3 and the system has been running great. So I know it isn't a hardware problem. Unfortunately, I can't get a diagnostic dump to help figure out the problems with 6.9.2. My signature has my hardware configuration listed if that helps. Dale

Just to be clear if I post Diagnostics it will be for version 6.8.3 because each time I tried under 6.9.2 it failed to complete.

I rolled back to 6.8.3 and I was able to do the steps you outlined. However, I don't think the mover did what it was supposed to do (see the attached screen print). Don't I need to change the pathnames in the Docker settings to point to the folder in the pool?

Update: I rolled back to 6.8.3. Everything except the cache drive came back. I restored the cache drive setting and I am now able to run mover to transfer some files to the array that never were moved under 6.9.2. I reenabled Dockers and all my docker containers came back and started. Plex is running again! I'd say at least for me 6.9.2 is a no-go.

Another problem: I cannot access any of my shares from the network. It shows the array is up and a parity check is running, but I have no access to any folders from my Windows PC.

Thanks but it seems that unRaid is crashing on me so it is constantly running parity checks. I was able to stop the Docker service, I had no VM services active, I set the appdata and system to Use Cache Pool: Prefer, then ran the mover. I don't see anything changing in the cache. I ran unRaid 6.8.3 for nearly 500 days straight with no issues. I updated to 6.9.2 and it's been a nightmare each day.