Jump to content

craigr

Members
  • Content Count

    287
  • Joined

  • Last visited

Community Reputation

4 Neutral

About craigr

  • Rank
    Advanced Member

Converted

  • Gender
    Male
  • URL
    http://www.cir-engineering.com
  • Location
    Chicago USA
  • Personal Text
    Video Calibration Engineer

Recent Profile Visitors

864 profile views
  1. Man I had forgotten how unRAID is supposed to run. Been back on 6.6.7 all of about 10 minutes and everything is sooooo much faster. Even torrents are coming in 30% faster than top speed on 6.7.2. Crazy. craigr
  2. Well I'm now back on 6.6.7. I can't deal with 6.7.2 anymore. Fingers crossed for a fix soon. craigr
  3. I just updated a docker on my server and it ground to a halt and took forever to install the update. After that, my iowait remained very high even after the docker was done installing. I had to reboot my server to get it to come back down and become usable again. This is really not good. The strange thing is that it's fine for a while after a reboot. craigr
  4. Does anyone know if the new beta with the new Linux kernel solves this? Thanks, craigr
  5. Well, add me to the list as well. I am having this issue big time. craigr
  6. Wow, thanks! I hope this gets fixed soon Best, craigr
  7. I'm having trouble isolating what is causing IOWAIT to consume huge chunks of CPU every 30~45 seconds. I first thought it was the new PLEX docker, then I thought it was "Folder Caching" app. Disabling either of these allows the CPU to remain normal for a while, but later it's utilization goes up again. Also, yesterday with the command prompt I deleted a directory (share) and that lowered the CPU utilization for a while ?!? The screen grab shows the CPU during a file transfer from the cache drive to the array. This file transfer goes a bit slower than normal. I tried copying it twice from cache to the array and both times it slowed down and both times it wrote to a different data disk. This makes me think I may have an issue with either the cache disk or parity disc? I am puzzled I've changed a lot on the server lately including swapping out an 8TB for a 10TB cache drive, installing NORCO 3-5 drive pods, and a few other things... Attached are a screen grab and diagnostics. Any help would be appreciated. Thanks, craigr unraid-diagnostics-20190823-1906.zip
  8. Great points and I hadn’t thought about that! The disks are only 50% full so that gives me a 50/50 shot even if the drive data was bad. I feel even better 🤗 craigr
  9. Oh, the other thing is I have done five parity checks since then and all have had zero sync errors. craigr
  10. Great Yea, there are lots of folks it seems that have issues with preclear. I have used it a lot over the past year as I expanded my server and have never had any issue using it. I seem to recall at one point having it installed was causing some error messages in the log so I uninstalled it and only reinstalled when I wanted to use it. Preclear has been installed on my server since this incident, and has not caused any more error messages in my log. Yes, I believe WD attempts to read back the data and as long as the dive thinks it got it right, it does not trigger a read error, but adds the degraded sectors to pending reallocation. Then, if the sectors are written to correctly, the pending sectors go back into circulation being considered healthy and not reallocated while also no longer pending. Its actually totally possible that the sectors were read correctly and that I truly had two parity sync errors. I like to believe this because all of my data is still perfect in this scenario Each preclear pass reads the sectors twice, so my preclears would have written zeros to those sectors three times and read them six. I figured six good reads and a good SMART test were proof enough the drive is ok. That said, this drive will always remain suspect and closely monitored. However, it easily could have been a fluke though. I think my 18 AGW wires may have had some voltage drop with the length and load on them. The sectors could have gotten hit with a particle, there may have be a large vibration while the were written (sometimes simi trucks go up our street and the speed bump is right in front on your house), or who knows what else. Anyway, thanks again, craigr
  11. I did pull the drive and replace it. With the drive pulled, I ran three preclear cycles, the first of which allowed the pending sectors to be written and returned to service. After that I ran an extended SMART test which it passed. The extended SMART test is the same thing as in the WD Lifegaurd diagnostics utility. The drive is out of warranty, but I doubt WD would have done anything anyway because there were no reallocated sectors. All SMART data looks 100% perfect. After the testing I returned the drive to the array. It’s been several months and the drive has performed flawlessly since... I know now it’s more prone to failure, but the risk is pretty low at this point and the data on the drive is not worth more to me than the cost of a replacement drive Thanks for your help, craigr
  12. Well, my thought with dual parity is that unRAID could check the data against both parity drives. If both parity drives agree, but the data drive does not, than fix the data drive. However, in many situations I suppose that would corrupt a good piece of data. Sigh. Thanks again, craigr
  13. Thanks for the thorough answer. I really wish unRAID would use the dual parity to verify if the parity or if the data on a disk is wrong. I recently had parity “corrected” for a drive that had pending sectors resulting in two sync errors... oh well. I still don’t know if the parity was wrong or not, but I suspect parity was correct and the data drive had bad reads. I was not expecting any sync errors on that check and it was the first time I have ever gotten sync errors when I hadn’t expected them for one reason or another. I pulled the drive out of the array, ran three preclears on it, and then an long smart test. After the first preclear the pending sectors were not reallocated so I still hope their data was good. Best, craigr
  14. So I remember reading a while back that when using dual parity in unRAID, that when a parity check takes place and a sync error is found, that unRAID would tell me which disc had the error. Is this true? Also, if doing a parity check and a sync error is detected, does unRAID use the dual parity to check if the sync error is due to an error on the parity drive or an error on a data drive? In other words, when a sync error is found, does unRAID check to see if the sync error is from bad data on the parity drive or a data drive; does unRAID correct the data drive if it is the cause of the sync error? Thanks, craigr
  15. I ordered these lat night and specified 17 pass through covers and 3 end covers: https://www.ebay.com/itm/20Pcs-Black-Molex-4-pin-Punch-Down-Power-Plug-Connector-Cover-Standard-IDE-PSU/261963671519?hash=item3cfe4067df:g:JCMAAOSw9N1VoSqn I'm hoping they can take #16 wire, but I did the calculations and #18 wire will work... but #18 is close to the limit for my current power requirements. craigr