garycase

... Just for grins, here's what the PC-80 looks like

As Jonathanm noted, the key is to force as much air as possible directly over the drives. The BEST case I've ever used for an UnRAID build was a Lian-Li PC-80, which has a swing-out door with 3 140mm fans on it that REALLY give spectacular airflow directly across the hard drives you've mounted. You can use up to 4 5-in-3 cages in it, and with the extra air from the front fans I NEVER saw temps above the mid-30's, even during a parity check. Unfortunately, the PC-80 is no longer available (I've been looking for the past year to try and get one for a build of my own). The best airflow solution I've found for hard drives is the Icy Dock Vortex 4-in-3 units, which have a 120mm fan in front that blows directly over the drives. I've found that this unit keeps my drives about 6-8 degrees cooler than the 5-in-3 units I replaced, which had 80mm fans in the rear "pulling" air over the drives instead of the larger fans blowing a much higher volume of air directly onto the drives. https://www.newegg.com/Product/Product.aspx?Item=N82E16817994171&cm_re=Icy_Dock_Vortex-_-17-994-171-_-Product If anyone happens to know where to find a PC-80 please let me know

Look at the UPS settings [Settings - UPS] and confirm UPS support is enabled. Also try a different USB port on your PC. If your system has both USB v3 and USB v2 ports, try a v2 port.

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]

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.

+1 Absolutely -- this is a GREAT change

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).

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

Yes, I've seen MANY instances of MAGIC in the 42+ years I've had computers at home

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.

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.

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).

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).

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 ...

This seems to show a GB connection, so I'd think it would be able to connect for the update checks.

Yes, it should have a connection. It had no problem getting the update from 6.3.5 and the checks always worked fine then.

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.

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.

@landS Thanks for the heads up. Just upgraded my D525 and the GUI is indeed VERY responsive. Just kicked off a parity check to see if there's any improvement in that -- initial look doesn't seem promising (~ 50MB/s), but I'll leave it alone and see just how long it takes. The slower data transfers and MUCH slower parity checks relative to v5 are frustrating, but something I've simply decided to live with. It'd be neat if these got resolved at some point, but I doubt that will ever happen. I routinely got over 100Mb data transfers with v5, and get ~ 75Mb with v6; and the parity check times went from a bit over 8 hours to over 15 with v6 ... I'll see what 6.4 takes in about 15 hours . It's a bit frustrating that my 15TB server using 3TB WD Reds takes longer to do a parity check than my 48TB server with 8TB HGST NAS drives on an old C2SEA motherboard with a Pentium E5300. But the simple fact is the slower data transfers and longer parity checks really don't matter -- and the MUCH better GUI responsiveness is REALLY nice with this new version.

I'd go with the NAS drive for its improved resistance to vibration and the longer warranty. Not sure where you're looking to buy these, but at Amazon, Newegg, etc. there's only about $20 difference in the prices -- hardly what I'd consider ".... significantly more expensive."

Indeed a very special case

The pre-clear signature being in the MBR explains why the original even parity ("Parity 1") works with all pre-cleared disks; but I don't see how Parity 2 can be valid with this approach. In any event, simply re-running the parity sync is certainly the safest approach anytime you modify disks in the array.

Well, first of all, that won't be true for the parity #2 (since it's a different parity computation than the simple even parity for parity #1). Second, the drives aren't ALL zeroes after a pre-clear => they have a special "pre-clear signature" that is cleared by UnRAID when you add a pre-cleared drive to an array. I suppose that IF you had an even number of drives (including parity) that would still work for parity #1, since even those bits that are a "1" would still add up correctly; but if you had an odd # of drives parity #1 would also be incorrect.

Johnnie, Just saw this. I don't think this is accurate. A parity sync has already been done with the current content of the drives. If you then pre-clear all of the drives, they will now have all zeroes (likely different than what they initially contained) ... so the parity will NOT be valid for this changed content. Pre-clearing the drives lets them be quickly added to an existing array without impacting parity; but pre-clearing a drive that's already in the array will change the content of the drive -- invalidating parity. [As an aside, I'm not sure that pre-clear will LET you do a pre-clear on an array drive, so this may all be moot.]

An update after another year -- I finally decided I simply didn't care about the speed issue, so I updated this system to 6.3.5. As expected, parity checks now take a bit over 16 hours (nearly double what they do with v5), and read/write speeds are appreciably slower => but the reality is I still just use this system as a "pure NAS" and the speed simply doesn't matter. I didn't do the upgrade for improved security (although that's a nice extra benefit) -- I simply did it so all of my UnRAID systems are running the same version. r.e. last year's comments about needing the extra security if you have any exposure to the internet -- I agree; but this system has no Dockers, no VM's, and only one plugin (CacheDirs) -- and I suspect most folks with D525-based systems have similar setups. If you want to do more, you really need more "horsepower" than the dated D525 provides. But for basic NAS duty it's hard to beat this system with it's 19 watt idle power consumption. It conceptually still bugs me that v6 is SO much slower running a parity check ... there's simply no technical reason why that should be the case => but I'll just live with it. landS => Have you by any chance discovered any further "tweaks" that help with v6 disk speeds?