BF90X

Long story short, the parity appears to have gone back to normal. I tried so many different things, I have no idea what fixed it. -Updated BIOS -Updated to UnRaid 6.10.1 -I tried one of the drives, it originally did not work. (Now that it's working, I did try the other drive instead) So that might be it? -Tried to boot UEFI instead of legacy (Literally hours trying but no luck) -At some point, I wasn't even able to boot with legacy due to the AER issue. I added the following to the syslinux, nvme_core.default_ps_max_latency_us=5500 pci=nommconf Already had, pcie_aspm=off I am still seeing the "Hardware error from APEI Generic Hardware Error" but not as much. The only major issue I am seeing for now is that one of the 2.5 inch drives on one of the ZFS pools is failing. Waiting for the replacement. prdnas002-diagnostics-20220524-1235.zip

Thanks for sharing that information, I will follow the steps on that link. Ohhh, I guess that's why core 6 is maxed out. Everything else seems to be working properly. I run docker containers and a coupe of vm's without much issues. One of the steps I tried to troubleshoot the parity rebuild issue was to do a new config. Also, pre-cleared the drives as well. I rebooted on safe mode and try the rebuild as well but got the same speeds. Did not look at the CPU usage when I did that though.

Thanks for the input @ChatNoir & @JorgeB I updated the firmware of the HBA and added a temporary fan for additional cooling, ordered a few items to come up with permanent solution to ensure the HBA has better cooling. After making these changes, I am still seeing the same issue. Might not be related but at some point after upgrading to 6.10 I notice I was getting a lot hardware errors. May 23 05:45:24 PRDNAS002 kernel: {20}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 512 May 23 05:45:24 PRDNAS002 kernel: {20}[Hardware Error]: It has been corrected by h/w and requires no further action I looked around online and found that someone had to run the following command to eliminate them, setpci -v -s 0000:40:01.2 CAP_EXP+0x8.w setpci -v -s 0000:40:01.2 CAP_EXP+0x8.w=0x2936 Attached is the new diagnostics. Appreciate all the help. prdnas002-diagnostics-20220523-1207.zip

Hello, I was wondering if someone could help me identify why my parity rebuild is slow. Some of the last changes were, - Installed a lsi sas3224 about 5 months or so ago - Replacing all my Seagate drives (Data Drives) I am getting roughly 10-20 MB/sec on the rebuild as of right now. I also have three 3 separate zfs pools, need to replace a drive on the hdd pool. The other two ssd and nvme are working properly. Attached is the diagnostics. prdnas002-diagnostics-20220523-0047.zip

Hello, I am experiencing issues with buffering as well. Media doesn't appear to start buffering, stop it and try again and then it would sometimes work. Is there anyway possible to revert back to a previous release of the docker container?

Thanks for the feedback, I appreciate it. It seems like that didn't work for me. It actually caused one of my parity drives to generate a significant amount of errors due to the reboots I had to do to get the drives to mount properly.

Having the same issue over and over again. Were you able to find a fix? It's starting to get really frustrating.

Thanks!

Hello, I am experiencing the same issue. I even started from scratch but now I have even more movies where is able to see the directory but not the files within those directories.

Quick Question, Has anyone else been getting this error message? 2019-12-26 14:31:35,294 DEBG 'radarr' stdout output: [Warn] HttpClient: HTTP Error - Res: [GET] https://radarr.aeonlucid.com/v1/update/master?version=0.2.0.1450&os=linux&runtimeVer=5.20.1: 404.NotFound {"errorMessage":"Latest update not found."} 2019-12-26 14:31:35,298 DEBG 'radarr' stdout output: [Error] TaskExtensions: Task Error

My aplogies, please disregard. It was my pfblocker causing the issue. Rebooting after update now.

Having issues upgrading. Getting the following message, plugin: installing: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg plugin: downloading https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg plugin: downloading: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg ... failed (SSL verification failure) plugin: wget: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg download failure (SSL verification failure)

Was there an update recently? It seems to be working properly again and I haven't changed anything.

Thanks for your response. That is correct, my unraid server is in the ip address range 192.168.1.0/24 My VPN provider is PIA and I didn't experience issues before the ISP change. My router is also the same, I am using Pfsense which was getting the hand off from the modem before and now it's getting the hand off from the FIOS circuit. I haven't experience any issues with other docker containers.

I followed the steps from the link. After reviewing it, it seems that VPN connects but the container page doesn't load when it is active. When I turn off VPN, I am able to access the container page and it loads properly. Thanks for your help. supervisord.log

Hello, I just recently change my ISP from Xfinity to Verizon FIOS. After I cut over to the new ISP and now I am unable to get my PIA VPN started. I tried changing the opvn file to TCP or IP but it didn't work. Once I start the container it starts to loop with the following message, 019-08-06 20:50:20,166 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:50:50,305 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:51:20,446 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:51:50,584 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:52:20,725 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:52:50,862 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:53:21,004 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:53:51,144 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:54:21,282 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:54:51,429 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:55:21,577 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:55:51,722 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:56:21,862 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:56:52,002 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:57:22,142 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:57:52,280 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:58:22,419 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:58:52,558 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:59:22,696 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 20:59:52,834 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:00:22,973 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:00:53,112 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:01:23,251 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:01:53,390 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:02:23,528 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:02:53,668 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:03:23,807 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:03:53,947 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:04:24,085 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:04:54,224 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:05:24,362 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:05:54,500 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:06:24,639 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:06:54,780 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:07:24,916 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:07:55,054 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:08:25,192 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:08:55,331 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:09:25,468 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:09:55,607 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:10:25,745 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:10:55,884 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:11:26,022 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:11:56,161 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:12:26,301 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:12:56,440 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:13:26,577 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:13:56,714 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:14:26,852 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:14:56,991 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:15:27,129 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:15:57,266 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:16:27,406 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:16:57,545 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:17:27,684 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:17:57,822 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:18:27,960 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:18:58,098 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:19:28,236 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:19:58,376 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:20:28,514 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:20:58,652 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:21:28,791 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:21:58,928 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:22:29,067 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:22:59,205 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:23:29,343 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:23:59,482 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:24:29,621 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:24:59,758 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:25:29,898 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:26:00,036 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:26:30,173 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:27:00,312 DEBG 'watchdog-script' stdout output: 172.217.10.100 2019-08-06 21:27:30,450 DEBG 'watchdog-script' stdout output: 172.217.10.100 If someone can please help me get the proper configuration done so I can get this working.

Thanks S80_UK That was a fantastic recommendation, I didnt even know that plugin existed. I am currently running the build process. Sent from my SM-G955U using Tapatalk

Thanks for your response. Forgot to mention, What if you have taken the parity drives out of the mix. Trying to move files between the disks so I can encrypt them. I understand removing the parity drives increase the risk of lost of data but It would take me forever if I was using them. Another task I want to accomplish is that I want to re-structure how each share organizes the files between the disks so I was also wondering if UnBalance could move files simultaneously.

Hello, I was wondering if krusader could move/copy multiple files simultaneously to fully saturate either the network or speed of the disks.

Hello, Is it possible for UnBalance to move multiple files at a time from one disk to other disks? When I run a move job, it queues up a list of files it will be moving but only moves one file at a time. It would awesome if I could setup multiple jobs to move files between multiple disks. Queue #1 - Move files from disk 14 to disk 15 Queue # 2- Move files from disk 16 to disk 2 and so on.