garycase

Interesting point in the results from RockDawg's test. It appears the "unthrottled" is the best found during pass 2 and ignored pass 1. Noted something else: Look at the results of test #1 compared to the almost identical test #36: 1 | 1408 | 768 | 512 | 101.9 MB/s 36 | 1416 | 768 | 512 | 91.6 MB/s Really strange. The only difference (aside from an insignificant 8 strip difference in the total allowed) is the 4 min duration vs. 3 min I have to wonder if this is related to the virtualization. RockDawg: I assume your controller is passed through -- correct?

VERY interesting. It would be very interesting if you would: (a) Post your system's hardware configuration details; and (b) download the new v2.2 of Paul's script and run it ... posting the results here. [it will also find your optimal value even better, since it looks "downward" for those systems that have their best performance at the low end of these values]

No problem. When you replace the controller card, post your new "tunables tester" results so we can see just how much things improved (I suspect you'll be amazed) ... if you get rid of those 250/333GB platters you'll see yet-another big jump. Difficult to really predict, but I'll go out on a limb and estimate that the new controller card will put you in the 60-70MB/s range; and if you then get rid of the small platters you'll be well over 100MB/s (although that may also require that you shed the 500GB platter units as well)

jbartlett => Please post the detailed results of your run of Fullauto with the new v2.2 that Paul created especially for you. Most interesting to see just where your system optimizes. And please post the full system configuration details (as I already asked for earlier). Both Paul & I are certainly very interested to see just what the system config is that optimizes at such low values

I'll take a 5400/5900rpm 1TB/platter drive over a 7200rpm lower-density unit anytime. There IS, however, one area where the 7200rpm units still easily outperform lower rpm drives ... they have better access times. So STARTING a transfer will be quicker on a 7200rpm unit, even though the transfer rate will be faster on the drive with higher areal density (assuming the difference is enough to make up for the rotational speed difference). So, for example, on a desktop with both Seagate DX and DM units (I assume that's what you have), the DX drive would be a better place for the Windows page file, since these are all small transfers where the quicker access would be beneficial. Nevertheless (as I noted above), when buying new drives I ONLY buy 1TB/platter units ... there's a lot of conjecture about whether WD's new 5TB WD Reds (due in January) are going to be 5 platter 1TB/platter units or 4 platter 1.25TB/platter units. I sure hope they're the latter !!

Completely agree. As your long post in Reply #94 above notes, the methodology you used here does a nice job of showing the impact at various settings for the sync_window, while still maintaining reasonable stripes and write_limit values. Folks are certainly free to adjust any of those parameters as they see fit to see what impact it has on their system. As you may recall, I did a LOT of testing on this a few months ago ... probably ran 30 parity checks in a 10-12 day period ... to find a reasonably optimum setting for my system. I was curious whether this utility would do better ... and it did indeed find a range that shaved another 8 minutes off my parity checks !! (at a cost of a bit of additional RAM) I think any read impact that optimizing parity check performance has is just as likely to be due to disk thrashing (as the read request(s) are satisfied) as it is from any stripe settings. The best parity check setting should keep the disks fully engaged, so any read or write activity is going to thrash the disks involved (and simultaneously "halt" the parity check while that read/write request is satisfied). It's easy to see how this may cause a few "hiccups" in video streaming during a parity check ... but that's not really due to "optimizing for parity" => it's a byproduct of the fact that if you ARE optimized for parity, the disks are VERY busy, and any attempt to do a high-bandwidth transfer at the same time will result in thrashing that may cause a few minor delays. That could happen during any parity check ... whether or not you're optimized for its performance. Bottom line: While not a panacea ... and certainly not a utility that really "optimizes" parity checks, as it doesn't do any real analyses of all possible ranges (i.e. it certainly didn't find the weird anomaly in jbartlett's system), your utility does a VERY good job of finding the likely best ranges ... AND providing a simple tool for a user whos system is outside of those parameters to look at the data and rerun the test to look at ranges that work best for his/her system. I can't image needing to go any lower than 128 -- but on the other hand, allowing even lower values in "Manual" mode wouldn't hurt anything ... so perhaps you should set that threshold to 32 or 64. I can't imagine that a value that low will be "optimal" for anyone => but then again I'd have never anticipated the results jbartlett had

An understatement jbartlett ==> Please post your configuration details !! I suspect you have very little memory in your system ... is that correct? Or perhaps a LOT of plugins that are using significant RAM. In any event, the specifics would be very interesting.

Jardo => You have a VERY nice build, but have two significant "flaws" that are slowing things way down. As I noted above (and others have as well), your PCI-X controller in a PCI slot is a MAJOR bottleneck for performance. In addition, you have several drives that only have 250GB or 333GB platters -- note that this means they provide 1/4th to 1/3rd as much data per revolution as a new 1TB/platter drive !! Your parity drive, Seagate 3TB drive, and probably your 3TB EZRX drive are all 1TB/platter units (there was an early version of the EZRX that used 750GB platters, but assuming yours is recent it will be 1TB/platter). Your WD15EARS is a 500GB/platter unit. The WD20EARS could be either 500GB/platter or 667GB/platter (depending on specific version). Your WD10EACS is either 250GB/platter or 333GB/platter (very slow). Your WD10EAVS is 333GB/platter. Your WD10EADS is either 333GB/platter or 500GB/platter (again, depending on specific version) The first thing you want to do is absolutely replace your controller card. But the next big performance gain you could do is to replace your 3 1TB drives with a single 3 or 4TB 1TB/platter drive. That would get rid of all 250GB and 333GB/platter bottlenecks. Then if you replaced your two EARS units with a 4TB 1TB/platter drive you'd probably have all 1TB/platter drives => and with the other characteristics of your system (very high-end Haswell setup) you'd have a VERY nicely performing system !!

Not at all surprising. The 1TB EACS drives were originally released with 4 platters holding 250GB/platter; later versions had 3 platters with 333GB/platter. In either case, compared to more recent drives with much higher Areal density platters, those are very slow. The newer EZRX units, for example, are all 1TB/platter drives ... so you get 3 to 4 times as much data per revolution from the platter !!

Absolutely !! You've got 5 drives connected to a PCI interface card !! Note that although your card supports a much higher bandwidth (since it's PCI-X), you're using it in a PCI slot, so it's throttled back to PCI speed ... and you're sharing it with 5 drives !! And since parity check speed is limited by the slowest drive, those drives on the PCI controller are killing your speed. Replace your AOC-SAT2-MV8 with the PCIe version (SAS2LP-MV8) and you'll see a BIG improvement !!

There's an issue with the -l (list) option in pre-clear when running under version 5. It will list ALL of the drives, whether or not they're in the array unless you (a) Start the array and (b) access the Web GUI (once is enough). Then the "preclear_disk.sh -l" command will correctly list only those disks outside the array. You don't, of course, have to bother if you're CERTAIN which disk you want to pre-clear. But it's a nice "sanity check", and certainly worthwhile to confirm you're picked the right one. I don't know if Joe L plans to modify the script to correct this or not -- he may be waiting until v5.0 is released before making any changes.

Simple fact is that a VERY high percentage of drives that show issues during pre-clear do so during the first pass ... so you're probably just fine. MOST drives added to UnRAID arrays are NOT pre-cleared ... so just doing it at all is a much better integrity test than most get. ... but a separate dedicated box to do pre-clears is a good idea -- it's also a good idea to always have a pre-cleared spare ready in the event of failure.

That boot option is no longer presented -- it was removed in RC15. Clearly you could still add a mem=4095 parameter line manually, but at least according to limetech this issue was resolved long ago (RC15). ... and the issue is marked as "Solved" in the OS 5.x issue list: http://lime-technology.com/forum/index.php?topic=27788.0

That issue was never fixed. Only a workaround was put in syslinux.cfg that lets you boot in 4GB if your physical RAM is more than that. The 4K boot option was removed after RC14. The release notes for RC15 noted that a newer kernel was used, and that the 4k option had been removed. The option hasn't been in syslinux.cfg since, and the issue isn't listed in the Release 5 issue list. It certainly won't hurt to try adding a mem=4095 limit to your config (or simply remove 4GB) ... but I thought this had been resolved. If you're running RC14 or earlier, I'd try simply upgrading to RC16c first.

Something clearly needs adjustment -- that's even slower than I'd expect with PCI controllers. Detail your hardware configuration and what disk drives you're using. That kind of speed sounds like IDE drives with 40-wire cables !! But that's VERY unlikely on a system with an i5. Another thought: Are you running RC16c? There was an issue with > 4GB of RAM in an earlier release candidate that caused very slow speeds. If you're not running the latest RC, upgrade to it and run the test again.

The best choice for the PC-Q25B is to use an SFX power supply. This works very well: http://www.newegg.com/Product/Product.aspx?Item=N82E16817256063 as does the modular version: http://www.newegg.com/Product/Product.aspx?Item=N82E16817256084

I would definitely NOT add that drive to the array until you've aborted the preclear and at least checked the final SMART values. ... or better yet run the manufacturer's diagnostics on the drive.

Very nicely done Paul => I'm going to run it on both of my systems just to see how well I did on setting the tunables.

Is that updating periodically? [is the elapsed time changing?] If not, the system's hung. If so, the drive is likely bad and the preclear is having problems reading everything. The pre-clear itself is already done ... what is' doing now is nothing more than seeks and reads (no writes). I'm not aware of an option to JUST do the post-read. You can just do the pre-clear (skipping both pre-read and post-read cycles); and you can skip the pre-read; but I don't think there's an option to do what you've asked here.

The SMART values all look fine. What does the PreClear report look like? [it will be in the preclear_reports folder on your flash drive.]

Yes, those look very good. No real issues with changing parameters; and all zeroes on the reallocated sector counts. Definitely what you want to see after a pre-clear.

Good plan. Note that Seagate reports a lot more of the "raw" data than most other manufacturers do in their SMART data, so it's no uncommon to see very high raw read error counts, and ECC correction counts. As I noted before, and as Joe just noted as well, what you need to watch for more than the raw counts is changes in the "value" (lower = worse), and especially numbers that are approaching the thresholds.

A high number of ECC recoveries indicate there are data errors that have been corrected via the ECC capability ... i.e. one bit was bad, but the error recovery mechanism could correct the data. When this gets high enough to start dropping the SMART value (in your case to 36) it's something you definitely want to watch. The interesting thing is it WAS at 23, but improved during the pre-clear. It may simply mean the disk needs to be re-written a few times to refresh the sectors. If you're going to use that for parity, I'd first zero the drive 2 or 3 more times and see if that value continues to improve. You can run "preclear_disk.sh -n /dev/sdx" and it will JUST do the actual pre-clear (zeroing) of the disk ... this takes about 1/4th the time of a full cycle. Then look at the SMART report and see what it looks.

Your report looks fine for all 3 disks. There are 3 files generated for each disk you preclear => the "before" SMART report (preclear_start); the "after" SMART report (preclear_finish); and the summary report (preclear_rpt). I always look at the summary first => the key things to look at are those SMART parameters that have changed; and the re-allocated sector summary at the end. If there have been no significant changes in the SMART data, and the re-allocation counters are all zeroes; then the disk looks pretty good. You should then look at the final SMART report to be sure there weren't any attributes that were already failing and simply didn't change (so they wouldn't have been in the summary as a changed attribute). But in general if there aren't any notable changes shown in the summary, and you see six zeroes at the end (the re-allocated sector summaries), then the disk is fine. Note that there are a few attributes that can SEEM troublesome, but really aren't. Some attributes have very narrow differences between the normal count and their threshold counts ... so they'll be shown as "near threshold" even though they haven't changed and are fine. You may want to read a bit more about SMART parameters -- although I can tell you there is little definitive information available; so you just have to learn what matters and what doesn't. [And those can vary by the drive manufacturer]

Looks fine.