bobokun

I did as you suggested and I created a new config, removed both Disk4 and the old Parity drive to rule out all bad options. I put the new parity drive in that has successfully passed preclear at 180-200MB/S. Now when I start the array and it is rebuilding the parity it's extremely slow! I don't think it's the drives anymore because the new parity drive was precleared super fast. Do you think it could be my SAS HBA card? I have the Dell PERC H310. If it's not that then it might be the miniSAS to sata cables that I'm using. Either way now I'm at a loss once again what I should do. I purchased some new miniSAS-Sata cables and hopefully that helps. EDIT: I powered off my machine and decided to use just normal SATA cables for all 5 drives instead of using the HBA card. So now all my drives are plugged in using SATA cables to my motherboard. Parity drive starts rebuilding started off slow at 19MB/s-30MB/s but after couple minutes it ramped up to 126MB/s. I just realized my HBA card is plugged into a PCIE 3.0 X4 (In x8) slot. I'm not sure if I need to plug it into a PCIE 3.0 x8 slot would that help?

I don't think it's the DispSpeed utility that is incorrect because the past few months my parity checks have been extremely slow (fluctuating between 3.5MB/s to 50MB/s) and now when I try to do a parity check it runs at 150-200MB/s full speed with no fluctuation. Should I still replace the parity just in case? I think the read speeds are fine but write speeds still seem to be slow because when copying from cache drive to disk4 it is writing at 30MB/s. From my understanding DiskSpeed doens't test for write speeds only read.

I'm hoping some of you guys might have some insight on what is going on. So I ran the DiskSpeed test multiple times on all my drives but constantly it showed my Parity and Disk4 was very slow. This caused my parity checks to double in length the past few months because it would slow down to 3.5MB/S for hours and then ramp back up to 150MB/S. I figured I would need to replace both the Parity and Disk4. I started to preclear a new 10TB drive that I was planning on replacing my parity with and move all the contents from disk4 to disk5 so I can shrink the array. After waiting a couple days to move everything from disk4 to disk5 (remember it fluctuates from 3.5MB/s to 50MB/s max.. even with turbo write on), I finally have Disk4 empty. Before I send it back for RMA I decide to do a diskSpeed test one last time...shockingly all my drives are now running at full speed and I'm not even sure if I need to replace my Parity or disk4 anymore...Does anyone know the reasons why this might be the case? I'm afraid that it could be because Disk4 is currently empty and once Disk4 is no longer empty it will start to slow down dramatically again. The differences I can only think of is (I ran DiskSpeed without any other docker containers running.) I thought this could be the reason so I started up all my docker containers and re-ran the tests. It still ran at full speed. Another change I did was change the tunables in Disk settings from Tunable (md_num_stripes): 1xxx to Tunable (md_num_stripes): 8192 Here are the results for Disk4 and Parity. Disk4: Parity:

I'm seeing these in my logs recently. Has anyone ever encountered this error or know how to fix it? I tried searching on Google but I'm not sure what the problem is...

I understand and that's why I've added them on my exclude folders (as displayed on the screenshot) but it's still being monitored? I must be configuring something wrong but I'm not sure how I should fix it.

I've been trying to set up file integrity to get it to work but I'm not sure if I'm doing this correctly or not. I keep on getting BLAKE2 key mismatch on my libvirt.img and a lot of my nextcloud files: See example: BLAKE2 hash key mismatch (updated), /mnt/disk1/nextcloud/.htaccess was modified BLAKE2 hash key mismatch (updated), /mnt/disk1/nextcloud/appdata_ocdoy1vwt49l/appstore/apps.json was modified BLAKE2 hash key mismatch (updated), /mnt/disk1/nextcloud/appdata_ocdoy1vwt49l/appstore/categories.json was modified BLAKE2 hash key mismatch (updated), /mnt/disk1/nextcloud/appdata_ocdoy1vwt49l/appstore/future-apps.json was modified BLAKE2 hash key mismatch (updated), /mnt/disk5/vm backup/libvirt.img was modified Are these true errors?? I have these excluded and clearing it but every time integrity check runs it always finds these files mismatched. Here are my settings:

I've been using unraid for about 2 years now and I love the fact that it makes it so easy to set up docker containers and have everything running! Happy Birthday Unraid!!

Deleting those files/folders worked for me as well. Thanks!

Anyone else get this error when updating the nextcloud to the latest version? 16.0.2

How did you get it to run on python 2.7 in the docker container? As we saw the docker container only contains python 3 and python 2 wasn't installed. Did you install it manually inside the docker container to get it to work? Since we are both running the same container I would assume that it should work for myself if you managed to get it to work

I do have the script saved outside the container, and I also checked the python installed in the docker container is not 2.7 but 3.6.8. I do have the same docker container installed however I think the reason why it's showing 2.7 installed is because I'm running the script from unraid and not within the docker container. In unraid itself I have python 2.7 installed and it's connecting to rutorrent using the server_url variable in the script. It could be a permission issue but I'm not sure how to give permissions access to the script. When I copied the script I pasted it directly in unraid using the userscripts plugin I can edit the script directly. When running the script in a terminal window in unraid (not in the docker container) I am seeing the full error message, whereas previously it was truncated. Traceback (most recent call last): File "./script", line 18, in <module> torrent_name = rtorrent.d.get_name(torrent) File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in single_request return self.parse_response(response) File "/usr/lib64/python2.7/xmlrpclib.py", line 1493, in parse_response return u.close() File "/usr/lib64/python2.7/xmlrpclib.py", line 800, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: <Fault -506: "Method 'd.get_name' not defined">

Oh should I be saving this script inside the docker container? I Have the script saved outside and I was using the userscripts plugin to run it. Maybe that's why I'm experiencing the issue? If you have saved the script in the docker container how did you schedule a cron job inside the docker container to run the script?

I realized what I did wrong, I forgot to rescan the controllers after I swapped the sata cable to connect to my motherboard rather than the SAS2008 controller which is why I was getting those errors when benchmarking.

Sent you a PM with the debug file. Thanks

Disk4 isn't a shucked drive. I tried to replace the sata cable for disk4 and parity and connect it directly to the motherboard instead of the DELL H310 controller but now when I run diskSpeed it hangs on disk5 with the message below. Now I'm wondering if there is an issue with my H310 card or if it's my SAS to SATA cables. SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]: Scanning Disk 5 (sdd) at 9 TB (90%) - 0|9999999999|0 (64) Not sure if this helps?

How do I fix the xlmrpclib? Is this something that needs to be downloaded outside the docker? I have nerdtools plugin installed and python-2.7.15-x86_64-3.txz installed. Is there anything else additional I need to install?

Yes I tried running it multiple times and the outcome is the same

Please see attached HGST_HDN728080ALE604_R6GS94LY-20190530-1805 disk4 (sde).txt WDC_WD100EMAZ-00WJTA0_JEGW7S5N-20190530-1805 parity (sdi).txt

I recently ran a benchmark after seeing my parity check take a lot longer than normal. All my drives have been precleared and are less than 1 years old. My parity especially is less than 2 months old and it's shucked so I can't simply RMA it. Is there something I can do? I'm not sure why the speeds suddenly drop so much.

Traceback (most recent call last): File "/tmp/user.scripts/tmpScripts/rtorrent Cleanup/script", line 18, in torrent_tracker_status = rtorrent.d.get_message(torrent) File "/usr/lib64/python2.7/xmlrpclib.py", line 1243, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1602, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1283, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1316, in single_request return self.parse_response(response) File "/usr/lib64/python2.7/xmlrpclib.py", line 1493, in parse_response return u.close() File "/usr/lib64/python2.7/xmlrpclib.py", line 800, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: This is the error I'm getting. I think specifically "torrent_tracker_status = rtorrent.d.get_message(torrent)"

I tried that and I'm getting errors. Are you using plugin Userscripts to execute the script? At the beginning of the script did you put #!/usr/bin/python? I'm wondering if there is anything else that I missed. What version of python are you using?

Anyone else have any weird UI issues after updating? I'm not sure how to fix this.

I'm actually having some trouble getting the script to work. What port did you use to connect?

Thanks! Mine says: May 2 17:58:56 unNAS kernel: mpt2sas_cm0: LSISAS2008: FWVersion(20.00.07.00), ChipRevision(0x03), BiosVersion(00.00.00.00) It's okay that the biosversion is 0 right? Everything seems to be working fine