garycase

The BIOS in a motherboard that supports ECC will log detected ECC errors (i.e. uncorrectable errors) => but not single-bit corrections. Those are simply corrected on the module with no other interaction. I suspect there have been a LOT of single-bit errors corrected over those "48 running years" that you have simply not been aware of, thanks to the ECC Many single-bit errors result in strange behavior or crashes that folks just assume are "another Windows glitch" or just another "hiccup" that goes unexplained -- but in fact wouldn't have happened if the memory was error correcting. The cost difference these days is very nominal to have that protection -- I simply don't agree that it's a "pointless expense."

The motherboard is in-stock at Amazon: https://www.amazon.com/ASRock-Rack-Motherboard-C236-WSI/dp/B01B96248O ... and on e-bay: http://www.ebay.com/p/ASRock-C236-WSI-Mini-ITX-Server-Motherboard-LGA-1151-Intel-c236/1662018727

Basically the issue is simple: UnRAID will NOT span a file across multiple disks; 'nor does it "know" the size of a file you're writing to it until after the write starts. So if your current allocation method and/or split level results in a specific disk being used for a new file, if there's not enough room for that file the copy will fail. The minimum free space simply says "don't start a copy unless the target disk has at least this much space". This doesn't need to be "twice the size" of the largest file you're going to ever write -- that's just protection against expanding requirements [what you THINK is the largest file you'll ever write may prove to be too small in the future ]. The appdata shares with 0 min free basically say "as long as there's space available, use the drive" => they would fail if there wasn't space; but hopefully you're using a large enough drive that you're not going to have a space issue. Typically these would be on your cache drive, which is hopefully a good bit larger than you'll need for these shares.

Haven't measured this, but I'd expect Turbo write would nearly double your write speeds. Note that for a "normal" write there are 4 disk operations involved (or 6 with dual parity) ... the current contents of the disk being written to need to be read, as well as the contents of the parity disk(s); then the actual data is written and the parity disk(s) is/are updated ... with a full rotation of the disks involved between the read and write operations. With turbo write there's only one operation per disk => every disk except the disk being written to and the parity disk(s) are read in the appropriate sector for the parity calculation; then the disk being written to and the parity disk(s) are updated. So there's no waiting for an entire disk rotation. Note that there are actually two reads from the "uninvolved" disks on a dual parity system, since each sector needed for the appropriate parity calculation needs to be read ... but these reads can both be done during the same disk rotation. Since rotational latency is a significant component of the access time of a disk (8 - 11 ms for a full rotation depending on the speed of the disk), eliminating a full rotation is a significant gain in net write speeds. The initial seek and latency is likely slightly longer than what is being saved, so I'd not expect a doubling of write speeds, but it should be pretty close in most cases. You're correct that if you're using cached writes there's no difference in the initial write speed to the array. Turbo writes would still speed up the mover process, but that happens "behind the scenes" so wouldn't be apparent to the user.

You can put as many of them as you'd like in your server. WD's comment that "... WD Red NAS Hard Drives are designed specifically for NAS systems that have 1 to 8 drive bays " is a guideline, but not an absolute restriction. I suspect the 8-drive limit is to minimize any vibrational issues when 8 drives are mounted in the same cage => but even then the anti-vibration technology in the drives is unlikely to make any difference with more drives. Further, UnRAID doesn't work like a traditional RAID ... i.e. all drives aren't normally spinning at once (only during parity syncs/checks or rebuilds). Yes, UnRAID is a NAS (network attached storage) => but it doesn't act like many NAS units, where all drives are spinning at the same time.

As I noted above, you'd likely not notice any practical impact. However, there IS an impact -- it's just that it's likely masked in terms of the "feel" to the user. Consider a stream from a particular disk (any disk). In the absence of any other activity, the "next" read is almost always on the same track as the last one, or perhaps the adjacent track. If there is simultaneous write activity on different disk, using the "normal" write mode; then there's zero impact on those reads. But if turbo write is on; then for each write the disk you're currently streaming from has to seek to the appropriate cylinder for the write activity (to read the current contents); and then seek back to the area of the streaming activity for the next read of that stream. Total access time for a modern disk is typically in the 12-15ms range (seek plus latency plus actual data transfer). So with two extra accesses, there's an effective delay of about 30ms between reads for the streaming data. Assume that instead of just streaming a video, the "streaming" activity was copying a file from the server, which would be FAR more demanding of the system. If it was on a disk that was fast enough to saturate a Gb network, that would mean you were pulling 120MB/sec of data -- or, about 3.6MB in 30 msec. Most modern multi-TB drives have at least a 64MB, and often larger, cache -- so they would almost certainly have enough data already in the cache to satisfy the next read request with no delay at all. If the "next" read required a seek (i.e. was on the next cylinder) that might result in a very minor delay, but almost certainly not enough to cause any notable impact. If you forced a LOT of activity you could perhaps force a situation where you MIGHT notice an occasional minor "glitch" in a stream -- i.e. if you were streaming 4 or 5 different streams, all from the same disk; and were simultaneously doing 3 or 4 writes to the array from different clients using turbo write, you MIGHT notice the difference. But even then I doubt it.

If all disks are already spinning you shouldn't notice any slowdowns in streaming. It WOULD require a few extra seeks on the disk that was currently streaming, but these are fast enough that there shouldn't be any issues with a movie stream. It's the spin-up delay that can cause problems ... and since you don't have anything to spin up, you'd be fine.

Glad all's well. Assuming you have an available SATA port, you may want to consider adding a 2nd parity drive so you'll be better protected against any future failures. The distinct advantage dual parity provides is that if you have a 2nd drive fail while you're rebuilding a drive the rebuild will still complete successfully.

I'd still just do #1 => I think that's the "safest" approach; and it leaves the original drive still available for data recovery in case something goes awry.

Agree ... the stock Intel cooler is fine. The Noctua NH-L9i tdallen noted is a VERY good, and exceptionally quiet unit which would be better than the Intel => but the Intel is all you need and is not at all noisy, so there's really no reason to spend the extra $$ The 65w TDP limit isn't an issue with the Core i3 suggested above -- the TDP for that unit is well below that (51w).

Depending on how much memory you want to install, buy 2 of any of the following: http://www.newegg.com/Product/Product.aspx?Item=N82E16820242290 http://www.newegg.com/Product/Product.aspx?Item=N82E16820242165 http://www.newegg.com/Product/Product.aspx?Item=N82E16820242215 I'd probably pop in 16GB (a pair of the 2nd link above), which should be PLENTY for anything you're likely to do with this system.

tdallen's suggestions are good choices => but be sure you buy ECC memory. It makes no sense to buy a server grade board with a CPU that supports ECC and then not take advantage of error correcting memory.

Agree => writing to 2 different disks at the same time will take FAR more total time than doing them one-at-a-time.

It's not at all clear that the disk has any issues => when it was moved and UnRAID then disabled it, the write FAILED ... but in this case that very well may mean nothing was actually written. So there's a reasonable chance the disk is just fine -- but once UnRAID marks it as failed, it can't be simply added back. I would NOT rebuild it onto itself ... doing that eliminates any chance of recovering data from the disk just in case parity isn't in fact good and a rebuild results in corrupted data. That's why I suggested rebuilding onto a new disk as the best alternative. As for checking the disk on another system => any system that can read the disk's file format would be fine for looking at the disk. The most direct way is to install fsproxy on a Windows machine, which will then let you directly read your XFS formatted disk. http://nadrin.github.io/fsproxy/wikka5bf1.html?wakka=HomePage Another way to do it from within Windows with to use a virtual machine with a copy of Linux -- here's an example using Ubuntu within Virtual Box: https://medium.com/@matteocontrini/how-to-read-an-xfs-drive-on-windows-with-virtualbox-and-linux-942d74f4644f#.957kv2ir8 Finally, a bootable Knoppix DVD will let you directly read the files without bothering with any Windows software. http://knopper.net/knoppix-mirrors/index-en.html

Squid suggested what I'd call approach #3 => same as #1 except that you're rebuilding onto the original "failed" disk. This works too; but has the disadvantage that if anything goes awry in the rebuild you don't have the original disk to recover your data from. I'd suggest using #1 => if the original disk is indeed fine, then you'll have a spare disk (always a good idea, so you can immediately replace a failed disk in the future). ... either way, when you're done, be sure to do a parity check

You indicated you haven't run a parity check => but you DID do a parity sync, correct? i.e. you DO have an assigned parity drive. Assuming that's the case, you have a couple of options ... (1) You can replace the failed drive with a new drive and let the system do a rebuild onto the new drive. This will work as long as parity is definitely good -- it SHOULD be, but without having checked it after your initial sync you simply haven't confirmed that. Note that you will still have the old ("failed") drive available to try and read if the new disk doesn't rebuild correctly. (2) You can ASSUME the "failed" disk is really good and that you just unseated it. If you think this is the case, I'd attach it to another PC and confirm you can read the data okay => you could boot to a DVD/CD-based Linux distro so you can read the file system okay, and just browse it a bit to get a good feel for it. I'd also run a disk test on it (non-destructive so no data is changed) using a manufacturer's test (e.g. WD's Data Lifeguard). If you're confident it's good, you could simply do a "New Config" on your sytem including this disk and either let the parity disk rebuild OR check the "parity is already valid" box ... which would NOT do a new parity sync. The latter SHOULD be okay IF (an important IF) you have done NOTHING else on the system since this happened. #1 is the safest approach.

My nickel's worth on this ... (1) "PreClear" is no longer needed for its original function => i.e.clearing a drive BEFORE it was added to the array, so the array wouldn't be down for the time it took to zero a new drive (which can be MANY hours). That's why JoeL wrote the PreClear utility -- with Tom's blessing and cooperation by providing the details for a "pre-clear signature" which allowed UnRAID to "know" a drive had been pre-cleared. However, as noted above, the latest version of UnRAID does not take the array off line for this -- it simply clears the drive and THEN adds it to the array -- so the "clearing" function is no longer needed (doesn't hurt to do it -- it just doesn't save any array downtime). (2) An ancilliary function of the Pre-Clear utility was that it effectively tested a new drive, since it did a complete read pass (pre-clear) BEFORE it wrote the zeroes; and then did a complete verification of the zeroes (post-read), and Joe included a bunch of random seeks to further test the drive being cleared. It became the defacto way to "test" a new drive for any infant mortality issues. So ... the real question isn't whether or not you need to "PreClear" a new drive -- but whether you should TEST it before putting it to use. As Rob noted, you can get a lot of opinions on that ... but my take is you SHOULD test a drive before putting it in service, but there's no reason to go overboard on this, as most infant mortality issues will surface in an initial thorough test. What I do with new drives -- regardless of the intended destination (UnRAID or a PC) -- is connect them to a spare SATA port on my main desktop; run WD's Data Lifeguard; and do a Quick Test; then an Extended Test; then a full Write Zeroes; and then repeat the Quick & Extended tests. ANY error => I return the drive (doesn't happen often). Error free => put the drive in service. I used to also run a full pass with Spinrite, which is a VERY thorough test of a drive; but this takes a VERY long time (over a day with modern drives) ... and I simply decided it wasn't necessary [i found a few bad drives with Data Lifeguard; but never had a drive fail with Spinrite after it had passed the Data Lifeguard testing]. Until the most recent version of UnRAID, I would then run a "clear only" pass of Pre-Clear ( "-n" option) on any drives that were destined for one of my servers ... but I no longer bother with that. Some folks don't bother with any testing -- and as Rob noted, since this IS a fault tolerant server, it is true that the impact of an early failure shouldn't be data loss ... just a bit of inconvenience. Note that the mere fact of adding a drive to the array effectively "tests" a drive fairly well anyway, as long as you do a parity check after you've added it (which you should always do). Just adding a drive to the array will cause the entire drive to be written (cleared if it's a new drive; written with data if you're rebuilding a failed drive or upgrading the size of a drive); and then if you do a parity check the entire drive is read. Personally, I prefer to do an initial round of testing to weed out any infant mortality drives [i've had a couple of those over the years -- but have NEVER had a drive fail early once it passed my initial round of testing] ... if you discovered this while adding it to your array you may wonder whether it was the drive or some other issue with your system.

Absolutely agree => When I said "Good idea" I meant exactly that -- WARN the user, but definitely don't delete key fiiles from anywhere !!

In retrospect, I think you're right. I forget when that change was made, but now that you mention it, I do recall that it WAS made. I still like my on-flash keys to be simply Plus.key or Pro.key, but I agree it isn't necessary.

Agree ... as I noted above, this is absolutely the "... SAFEST approach " to ensuring you never have any key transfer issues like jonathanm outlined earlier. New test for FCP maybe Good idea.

Yes. And while it's probably obvious, this means you should keep good records for your keys, so you KNOW which key goes with which flash drive. e.g. I keep a folder on my desktop system called "UnRAID keys" -- and I keep a copy of every key I have renamed with the GUID. For example, a Pro key tied to GUID 1234 5678 1357 1234AB5678CD would be named: Pro -1234 5678 1357 1234AB5678CD.key Obviously, to use that key, I just copy it to the appropriate fllash drive and rename it to Pro.key

Agree ... as I noted above, this is absolutely the "... SAFEST approach " to ensuring you never have any key transfer issues like jonathanm outlined earlier.

Not sure what you are saying ... a flash drive has a unique flash GUID -- and the key file simply allows that flash drive to run UnRAID at a specified level (Basic, Plus, or Pro). Blacklisting a "key" is really just blacklisting a specific flash GUID -- I don't see any distinction. I DO, however, agree that the process outlined above, which can result in the wrong key being replaced, needs to be addressed. The SAFEST approach is to only put the key that actually belongs to a specific flash device on that device -- but if there are multiple key files on the unit, the replacement process should ASK which one to use.

As for where in the forum it's placed, here is probably fine for now -- at least until the "Auto" feature is actually implemented. No real reason to put more focus on it until then ... although it's much quicker than the standard read/modify/write method, it's still a good bit slower than using a cache drive -- but has the advantage that all writes are immediately fault tolerant (unlike with a cache unless it's a fault tolerant btrfs array). I really like the "Auto" setting, since it would make it trivial to switch to "high speed" writes if you're getting ready to add a lot of data to your array (Just click on "Spin Up" in the GUI before doing the writes); and otherwise only the minimal number of drives would be spun up.

Did you follow the instructions to do this on-line directly from the Web GUI? As long as you're using v6, this process is fully automated. See the details here: https://lime-technology.com/replace-key/