garycase

Moderators
  • Content count

    13477
  • Joined

  • Last visited

  • Days Won

    1

garycase last won the day on March 8 2017

garycase had the most liked content!

Community Reputation

36 Good

1 Follower

About garycase

  • Rank
    Advanced Member
  • Birthday 12/22/1947

Converted

  • Gender
    Male
  1. UPS Recomendations

    Just connect it to your UnRAID server with a USB cable. UnRAID's built-in UPS module will automatically recognize it -- nothing else to do unless you want to modify the default shutdown parameters [Settings - UPS]
  2. Should we enable "Write corrections to parity"

    This scenario would, of course, cause parity to be incorrect and generate parity errors. Yes, you're correct that a correcting check would then update parity so it reflected the current "... intentionally corrupted disk ..." => as it would have no idea that writes had been done to that disk. In a more realistic scenario, if the disk had encountered a lot of write errors while in the array, there would have been reported errors and the disk would have been "red-balled" ... in which case it would have been taken off line. You could have then done a rebuild to the same (or a different) disk and the original data would have been restored. You could do the same in your scenario by forcing a rebuild of the disk after you re-installed it, since YOU would know that it was corrupted. Basically removing a disk from the array and writing to it on a different system is never a good idea (except in severe recovery scenarios), since this will guarantee parity is no longer valid. If, instead of removing it and "intentionally corrupting" it, you had removed it and wrote a bunch of new data to it on another system, then the changes to parity with a correcting check would have been exactly what you wanted -- parity would now reflect the actual contents of all of the disks. The bottom line is that parity is not a panacea -- it does not eliminate the need for backups 'nor is it able to correct all possible corruptions. It simply provides insurance against a single (or dual) drive failure causing data loss as long as the system is working correctly.
  3. v6 on Atom D525

    +1 Absolutely -- this is a GREAT change
  4. v6 on Atom D525

    The 40's are fine for 7200rpm NAS drives during a high-stress activity like a parity check; but I'd definitely check what's going on with temps in the 50's. You may have had a fan failure. The Q25B (as you know) has excellent airflow, so it seems likely that either a fan is running too slow or it has simply failed. One of my other systems has 8TB 7200rpm HGST NAS units, and they also get into the 40's (44-45) on parity checks. They're in Icy Dock 5-in-3 cages, which have 80mm fans at the rear "pulling" air through the cage. I'm inclined to change to the Icy Dock Vortex units (I have those on another system), which has 120mm fans in front that push the air more uniformly across the drives, and does a notably better job of cooling. Clearly these aren't options with the Q25B, however -- and should absolutely not be needed. My Q25B temps never get above the mid-30's on parity checks with WD Reds (which are slower and cooler than the HGSTs) => I'd expect 5-8 degrees higher for the 7200rpm HGSTs, but certainly not into the 50's. 50-52 is still well below the rated 60 degree max, but it's not a range you want these to operate at routinely. If the fans are working, I'd replace them with higher airflow units (easy to do).
  5. v6 on Atom D525

    Yes, I've "fiddled" a good bit with the tunables. Tried the values that worked great with v5; tried the values LandS uses; tried the numbers in your picture (suggested as good for most setups by Johnnie Black); tried the results of Pauven's "tunables tester"; etc. Nothing seems to make any significant difference. Frustrating since with v5 it was MUCH faster. It's more a frustration than a real problem, however, as this is just a backup NAS and is still plenty fast enough to stream a video from it (although I don't use it for that). But on v5 transfers were ~ 100MB, while v6 gets around 70; on v5 a parity check took just over 8 hours (3TB WD Reds); on v6 they take 15. NO other changes. And it's not pegging the CPU, which is what I initially thought was the problem (in fact the first versions of v6 did peg it; but that improved markedly somewhere around 6.2 or 6.3). I fiddled with this a LOT about a year ago; then just decided to stay with v5 on this server; but a couple weeks ago I decided to just move it back to 6 anyway just so all my servers were on the same version. With the release of 6.4 I'm glad I did, as despite the disk performance reduction the BIG improvement in GUI responsiveness is really nice ... that alone is worth the lower transfer speeds and longer parity checks. [The longer parity checks are less of a nuisance than the slower xfers] I still like my trusty old Atom as a backup NAS ... it's rock-solid reliable and idles at under 20w
  6. unRAID OS version 6.4.0 Stable Release Available

    Yes, I've seen MANY instances of MAGIC in the 42+ years I've had computers at home
  7. v6 on Atom D525

    Agree. Just upgraded it to v6.4 and while the transfer speeds and parity check times are still the same (actually the parity check was 6 minutes faster than the last one I ran on 6.3.5), it's still MUCH slower than v5 ... but plenty "good enough". And the GUI responsiveness in 6.4 is AMAZING. That alone makes it worth running despite the slower speeds. I DO wish whatever is causing this performance hit would be resolved, but I doubt that will ever happen (it's not even close to pegging the CPU). Nevertheless, it's a great little NAS.
  8. unRAID OS version 6.4.0 Stable Release Available

    Update on this: I made NO changes; didn't ReBoot; didn't Stop/Restart the array; etc. => just did my usual Parity check to see if the update had any appreciable impact on parity check times (it didn't) ... BUT the Check for Updates is now working fine on both the Plugins tab and the OS Updates section. Just thought I'd try it once more before rebooting after the parity check -- and Voila! It works now.
  9. UPS for unraid

    If you're price sensitive, you may want to look at the CyberPower sinewave units -- they are often available for a few $$ less than APC. APC is the "gold standard" for UPS units, however, so if the difference is modest I'd go with them. I have several units from both makers, and they're all very reliable. I do, however, only buy their better sine wave units and none of the less expensive "simulated sine wave" models. No matter what you buy, be CERTAIN you have AVR (ALL of the sine wave units and most of the other units will have this -- only the very inexpensive models omit this feature).
  10. UPS for unraid

    That's an excellent unit -- not "overkill" at all. Plenty of capacity, pure sinewave output so you don't have to worry about any electrical issues for systems that are overly sensitive to distorted waveforms, etc. You may NEVER need to buy a replacement ... just get fresh batteries ever 3-5 years (~ $35 for a pair of the user replaceable batteries).
  11. unRAID OS version 6.4.0 Stable Release Available

    The ping results in a series of 64 byte packets being received until I hit Ctrl-C, which stopped it and gave the following results: GitHub.com ping statistics 58 packets transmitted, 58 received, 0% packet loss, time: 57075 ms rtt min/avg/max/mdev = 44.465/51.391/82.397/5.597 ms Just for grins, I backed up the flash on my main media server and did the update there as well. SAME results with update checks --- "Status: Unknown" for both the plugin and OS checks. It seems to show the check working okay ...
  12. unRAID OS version 6.4.0 Stable Release Available

    This seems to show a GB connection, so I'd think it would be able to connect for the update checks.
  13. unRAID OS version 6.4.0 Stable Release Available

    Yes, it should have a connection. It had no problem getting the update from 6.3.5 and the checks always worked fine then.
  14. Agree -- there's no "right" answer to this. I see no reason, however, to use a longer spin-down delay on parity. I'd just use the same value for all of your drives. FWIW I use 45 minutes for mine ... on the basis that if I'm using the server it's VERY unlikely I'd go more than 45 minutes between accesses, so it won't spin down while I'm still active.
  15. unRAID OS version 6.4.0 Stable Release Available

    Noted the following on 6.4: => On the Plugins page, clicking "Check for Updates" does a check, but after it's done still shows Status: Unknown for my only plugin (Dynamix Cache Directories) => On the new "OS Update" page in Tools, clicking "Check for Updates" does a check, but it also shows Status: Unknown after the check.

Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.