garycase

Thanks for the info. The temps seem fine for 7200rpm drives ... and clearly the parity check temps are "worst case" for an UnRAID array. I took advantage of a good rebate on a PC P&C modular PSU a couple weeks ago to prepare for this build (I was still debating between the Q08 and Q25 cases, so don't have the case yet) ... and before I ordered it I DID check Lian-Li's specs ... which show 180mm for the Q25 and 185mm for the Q08 as max PSU length. AFTER I received the PSU and had decided to use the Q25, I saw your thread and noticed how tight the CX430 was -- and it's shorter than the PC P&C. Clearly the 180mm (7.1") spec is WRONG. I have decided to use the case, however, so clearly I either need to use a CX430, another 5.5" unit; or an SFX unit. I think I'll just use the CX430, since it DOES fit and is likely a bit quieter than an SFX unit would be (since it's got a larger fan). I'll probably just cut off the unused cables. I'm also ordering some short left-hand SATA cables that should make it a bit neater on the back side of the drive cage. This is a good source for those if you ever want some: http://www.cpustuff.com/left-angle-to-straight-sata-cable/

This thread emphasizes one simple point about RAID arrays ==> they are NOT backups. They simply provide fault tolerance that makes it much less of a hassle when a drive fails. You should still have a backup of all of your data. IF you have the data backed up, the simplest way to replace the 2 old (and smaller than you'd like) drives is to simply replace them one-at-a-time with a new drive and let UnRAID rebuild the drive. This is a very simple process -- shut down; replace the old drive with a new one; and reboot. The rebuild does take a fairly long time ... and yes, it has to read all the drives -- but it's a very reliable process. The only issue is (as already noted) if you have a failure during the rebuild. The alternative of adding the new drive to the array changes WHEN you are running "at risk" -- but doesn't eliminate the fact that you will still be doing so. If you add the new drive, there's no "at risk" time during the preclear or while copying data from the old drives; but when you then remove the old drives and re-init the array you're at-risk while parity is being computed. Granted this is only one full read cycle of "at-risk" vs. 2 cycles if you replace both of the old drives. The safest approach is to be sure all of your data is backed up BEFORE you do anything that involves running the array "at-risk". I do my backups to a bunch of 2TB bare drives via an eSATA dock, and store them in drive boxes [These: http://www.amazon.com/WiebeTech-DriveBox-Anti-Static-inch-Hard/dp/B004UALLPE/ref=sr_1_1?ie=UTF8&qid=1348909976&sr=8-1&keywords=wiebetech+drivebox ]. It does take extra time -- everything I write to the array I also write to my current backup drive ... and when it gets full I store it in a DriveBox and insert another drive in the dock. But I have a complete backup of my 28TB UnRAID on drives that are safely tucked away in a fireproof & waterproof safe. If I had a 2 (or more) drive failures, I'd simply have to replace the drives, then copy all of the backup drives to the newly initialized array. (Yes, it'd take a long time, but only a few minutes of "my time" -- the rest would just be waiting for the copies to complete -- and there'd be NO data loss).

Hoopster, Getting ready to build a system in this case, and am curious about two things: (1) The ATX PSU is obviously a tight fit (but DOES fit). If you had it to do over again, would you use that unit again; or would you use an SFX PSU to allow more space in the case? (2) What are your typical drive temps? ... and how hot do they get during a parity check (after a couple hours)??

Thanks Joe, Invoking a web page with the "Spin Up" or "Spin Down" commands works just fine.

A brief note on parity checks ... Remember that all modern drives use zoned sectoring -- so their performance is far better on the outer cylinders than the innermost ones. So ... regardless of the controller-related performance issues (i.e. PCI controllers vs. PCIe x1 controllers vs. PCIe x4 controllers vs. on-motherboard controllers) ... the performance for a given drive will decrease notably as it reaches the innermost cylinders -- this is most noticeable in the last 15% or so of the drive. The result of this is that parity checks on a system with mixed drive sizes will slow down much more often than those on systems with all drives the same size. e.g. if you have 1TB, 1.5TB, and 2TB drives mixed; the parity check will slow down as it gets to about the 850MB point; then jump back up in speed at 1TB (as the 1TB drives are now no longer part of the process); then slow down again as it gets close to the 1.5TB point; then jump back up until it reaches the last bit of the 2TB drives. Unless you have a slow controller (e.g. a 4-port PCI controller) that can't keep up with the transfer rate of the drives, these drive performance issues are the most significant reason for the parity check rate varying during the process.

Thanks guys. I agree that at ~ 30w idle one may as well let it run 24/7. I notice that the 3TB drives are on the D525 version of the board, but hopefully the D510 version supports them as well. Supermicro gave a very vague answer to a question I sent to their tech support folks: "... X7SPA-F using Legacy BIOS. With latest release BIOS, motherboard all to detect 3TB install on SATA ports correctly. However, when user plan to install OS either Windows or Linux, it will on show 2TB disk space usable after finish installation." Not sure if this is a Yes or No I think I'll just buy one and give it a try -- worst case is I'll just use 2TB drives for this little server (which I had originally planned anyway).

I can easily turn on my UnRAID server remotely via a simple WOL command; but there are two other things I'd like to be able to do just as easily -- and I'm not sure how (if at all) these can be done. (1) Spin up all the disks. Clearly this is trivial with the Web interface (just click the button) ... but what I'm looking for is a simply command that can be executed as a batch file (or a scheduled task) to spin up all the disks a couple minutes before a scheduled middle-of-the-night backup utility runs. {Yes, they'll spin individually as needed, but I'd like the server to simply be at full speed when the backup starts). (2) Shut down the server. Again, simple with the web interface -- but is there an easy way to do this from a Windows command line? I know there's a simple utility that will let me schedule an automatic shutdown at a specified time -- but I'd like to do it when a specific batch file that can take a widely variable time to run has completed.

Rajahal, I've been thinking about changing my UnRAID system to the SuperMicro MBD-X7SPA-H-O board that you're using. It does seem like it'd be a great low-power board. Since you're using this board, perhaps you can answer a couple of questions ... (1) What's the idle power draw when all drives are spun down? (Preferably measured with a Kill-a-Watt) (2) Does Wake-On_LAN work correctly with this board? (3) Any "gotcha's" with UnRAID ... BIOS changes, etc. that are needed => or does it just boot as is? This seems like a perfect board to pair with a LIAN LI PC-Q08B and six 2TB drives for a relatively compact 10TB server. I'd be interested in any comments you have now that you've been using it for a reasonable length of time.

Okay, I had my first errors on my UnRAID box after months of error-free operation. At first I thought I had a failed disk, but that's apparently not the case. Summary: => Two days ago (Thursday), while adding some new movies to the "DVDs" share, the system seemed to hang .. so I looked at the UnRAID screen and (Ouch !!) saw ~ 300 errors on both disk 0 (parity) and disk 5. Interestingly, it was reporting the disk temperature for both of these disks as 0 (NOT a "*" like when they're spun down). My initial thought was I had a disk failure (likely #5) ... so I stopped the array and shut it down. The array shut down okay; and when I rebooted it, it still said parity was okay; but showed the errors on disk 0 & 5 in the "errors" column. => I cleared the stats ... so all columns were zeroes. Then I spent many hours running a comparison utility to confirm that everything I've copied to the array in the last couple months was okay -- everything tested perfectly. I keep a complete set of backup disks ... anything I copy to the array is also copied to a backup disk; when a backup gets full, I label it and store it in a fireproof file cabinet. Since disk #9 was fairly new, I ran a complete compare on both #8 and #9 ... and all files are okay. Note that a full disk (which #8 was) takes ~ 12 hours to compare, so this process occupied most of Friday. Note that these backup disks do NOT correlate with specific disks in the array -- I simply fill the backup disks; then store them; whereas the shares on the UnRAID server are filled based on UnRAID's algorithms ... but they do give me a complete backup of all files. => Next I ran a parity sync overnight Friday night. This found ~300 sync errors ... which were clearly related to the errors previously displayed. => After that was done, I ran UnMenu and selected the "File Check" option for disk #5, which was the disk that had displayed the errors. This completed with no errors found. => I then ran a parity sync again -- and it completed with zero errors. Question: Has anyone seen a similar set of errors? Anything else I should check? I'm leaning towards a "fluke" failure of the controller; perhaps a static anomaly; etc. I ran MemTest for 4 hours just to be sure it's not a failing memory module (no problems there) .. but can't think of anything else to test. UnRAID Pro v4.6 14 disks; SuperMicro C2SEA

You've already replaced the drive and confirmed that parity is good, so there's no reason to keep the old parity drive. Go ahead and add it to the array ... either as a new drive or to replace an existing drive.

"... i changed the cable... no difference then i plugged the server into a different switch/router... still no difference. " ==> Did you do this (change the cable; change the connection to a different router) for BOTH the server and the computer you're accessing it with? If EITHER of these has a network issue, the speed between them will be reduced. Since you have a spare router, try this: Connect JUST the server and a PC to the spare router -- nothing else (no internet; no other PCs; etc.) and then see what speed you get (Note that if it's not a gigabit router your speed will only be 100Mb ... but that will at least let you know that it's working okay). Once you've isolated WHERE in the network the issue is, you can replace the defective component. From my experience, the most likely culprit is either a cable or a bad port on a switch -- but everything Joe L listed is possible.

I can't really think of any reason to do this, but I can understand the desire to be "CERTAIN" that everything's consistent. As I understand it, UnRAID won't re-clear or re-format the disks, since they all have existing UnRAID MBRs on them. The simplest way to be sure the system "starts over" with these disks is to wipe out the current partition structure. Just boot to a a partition management tool with a bootable CD; delete the current partitions from the drives; and then boot to UnRAID with an initialized configuration file (disk.cfg). Then just create the new array. Before doing this, of course, either add jumpers to the drives that don't have them; or remove all of them from the ones that do. Since your friend's running 4.7, it would seem the better course of action would be to remove all the jumpers and set UnRAID to format these on 4k boundaries -- then any future changes won't require jumpering a new drive.

One HD, the others all standard DVDs (the vast majority of my collection are standard DVDs) ... using SMB. There are just two of us -- so the need to stream six at once is not very likely ... but I have six different places you can watch TV/movies (4 PCs tied to HDTVs, 2 extra computers), so I've tested with all six streaming at once -- all TV (from a Beyond TV Server), all TV (from a Sage server), all movies (from the UnRAID server), and combinations of the above. All of them work fine. Fully wired GB network with all Cat-6 cable. Writing data without a parity drive assigned is exactly like writing with a cache drive -- there's no extra overhead like there would be with fault tolerance in place. So your write speeds definitely seem slow ... either because the data's not coming off the Drobo any faster than that, or you've got some issue with your network that's causing the transfer speeds to be slow.

One other comment -- just noticed your last line, "... The only thing I can think it would add, is if I want to add a file to the array, whilst it is being used for streaming (presumably writing to it stops it being able to stream)?" No, writing to the array doesn't stop it from streaming. UnRAID is quite robust -- you can actually run a parity check, write to the array, and stream a couple movies all at once. Certainly exercises the drives a lot if you do that ... but it works I don't actually use the array when running a parity check -- but I have written new files to the array while simultaneously streaming six different movies.

No, that's not at all true. A cache drive will definitely improve your performance IF you have a GB network. On a 100MB network both your read and write speeds will be network limited (to ~ 11.5MB/s) ... so there's no reason for a cache drive. On a GB network you'll see write speeds to the protected array in the 30MB/s range -- less than half of what you could achieve writing to a cache drive. Remember that a single sector write to the protected array requires 4 disk operations, whereas a write to the cache drive is a single operation. Reads will generally be network-limited, but can get close to the disk transfer rate ... I usually see between 70 & 90MB/s. If you had a cache drive your write speeds would be close to those read speeds -- depending on the performance of the cache drive. Your Raptor would work very well for this purpose. VERY simple to test -- just install the Raptor (but don't assign it to the array) ... then write a few GB to a share on the array and note the transfer rate (or just time it); then shut down the array and assign the Raptor as a cache drive; then start it back up and write a few GB to the share again The 234MB/s described by Brit is completely useless with regard to UnRAID performance. That's a local Linux speed test -- NOT a test of access to the server ... i.e. no network involved. The high initial speed is NOT writing to the disk ... it's simply the speed at which data can be buffered in RAM. Note that by the time the 10GB test is written, the average write speed is 34.8MB/s ... and when it's read back the average read speed is 80.5MB/s. These are the REAL speeds the system is operating at.

I agree (as I said earlier) that with very large writes the EARS drives would "catch up" and pass a Raptor ... but that's unlikely to be the case in most scenarios, due to the network speed limitations. Even a finely tuned GB network will never exceed ~ 90GB/s ... and even if it was "perfect" (with no packet overhead and no retransmissions) it could only hit 125GB/s (125GB x 8 bits/byte = 1,000gb ... or a "perfect" transfer rate). EADS drives won't come anywhere close to 234MB/s -- that's FAR faster (more than double) than the platter streaming speed ... and 1.2GB is FAR more data than the 32MB cache can hold, so there's simply no way you can write at 234MB/s. I've seen outer cylinder READS hit ~ 115MB/s on an EADS or EARS drive on an internal SATA controller ... but even these will be limited by the network speeds when read from an UnRAID server.

r.e. your Raptor speed .... The areal density on the EARS drives is greater than that on a Raptor, so it provides a faster transfer rate for data streaming from the drive ... ... HOWEVER ==> the Raptor's average seek time is far better than an EARS ... ~ 4.5ms vs. ~ 12ms ==> so a Raptor will START a write well before an EARS will. Note a Raptor can write ~ 1/2 MB before the EARS will even start the write ... and can likely keep up with the network transfer speed of the incoming data -- so I doubt the EARS would ever catch up. If the drives were being accessed locally, the EARS would be better for large file transfers, since it would "catch up" and then pass the performance of the Raptor ... but with an UnRAID server that's limited by the network transfer speeds (even on a gigabit network you're unlikely to exceed about 70-80MB/s) the "head start" the Raptor has would not likely be overcome by an EARS. Bottom line: The Raptor is a fine choice for your cache drive.

I've built a couple systems using the C2SEA board ... unfortunately I don't have one here to look at, but I didn't change ANYTHING in the BIOS on those systems except to set the Power On option to "Turn On" and the default boot device to the USB flash drive. Did you disable the onboard BIOS for your 1430SA cards? That's necessary for them to function correctly with UnRAID ... although I wouldn't expect that to cause the shutdown issue you're seeing. I agree with Joe's comment -- it sounds like a thermal or memory issue. But you seem confident it's neither of those, so you may very well have altered something in the BIOS that's causing an issue. I'd reset the BIOS to "Load Optimal Defaults" ... then reset the boot device and leave everything else alone.

Thanks ... I'll add that in a few minutes. What impact does the "cache pressure" have? Is 100 "safer" than the default 10? ("safer" in the sense it's less likely to cause problems on the server) It's not clear to me what this parameter means -- I presume it influences when linux releases the cache .. is that right? What happens when copying new movies to the server? Does the cache simply get overwritten -- and result in spinning up all the other drives to re-read it? Or is the refresh rate of cache_dirs fast enough that the directories will still stay in the buffer? [i have 4GB of RAM] Is this influenced by "cache pressure" ?? I assume cache_dirs should be stopped before doing a parity check -- otherwise it would seem that it will be continuously reading directory info as the buffers get used by the parity check routine. [i never use my server during a parity check anyway]

First, SATA I vs. SATA II makes no difference ==> both interfaces are far faster than the data can stream off of the platters. But to answer your question ... (a) For reads, the read speed depends on the speed of the drive the data being read is on ... no other drives are involved in this. In most cases, the limiting factor for your data transfer is the network speed ... not the drive speed. (b) For writes, the speed is a function of the speed of both the drive being written to and the parity drive. To write one sector of data requires 4 disk operations: two reads and two writes. One each on the drive the data's being written to and the parity drive. So if, for example, one is a 5400rpm drive and one is a 7200rpm drive, the speed will be limited by the 5400 rpm drive ... although there are other factors (areal density of the drive; size of the drive's cache; etc.). If your network is a 100mb network, none of these matter -- both reads and writes will be limited by the network speed. If you're on a gigabit network, then you'll get the maximum possible write speeds, but your reads will generally be limited by the network speed (although the inner cylinders of 5400rpm drives will probably be slower than the network).

Joe, I've been thinking of adding this to my server for some time, but just want to be sure I do it correctly. Can you confirm that the following is the right process: (1) Copy cache_dirs to the root of the flash drive (2) Add the line cache_dirs -w -i "DVDs" to my "Go" script to cache ONLY the share named DVDs (3) Reboot the server Question: Can I eliminate #3 by logging in to the server and manually typing the 'cache_dirs -w -i "DVDs"' line? I'd like to preserve my current Uptime if possible ... also, is the download for cache_dirs in the first post of this thread the current version? I basically run UnRAID solely as a file server for my media collection (the "DVDs" share) and to keep a "Backups" share (that doesn't need to be cached). The only add-ons I have installed are UnMenu, the PowerDown and APC UPS packages. Is cache_dirs likely to cause any issues with these? I've read a bit about the need to sometimes increase the cache_pressure value -- does this make it "safer" ?? I like the idea of always-available directory listings; but do NOT want to do anything that may reduce the reliability of the server. If the versions make any difference, I'm running 4.6 now (updated about a month ago) ... and will probably switch to 4.7 after it's past Beta so any future EARS drives will be supported without jumpers (and to eliminate the need for a ULimit parameter).

Just curious what the long-time users opinions are r.e. the most stable, reliable version of UnRAID. I have a test server I put together last summer that now has 145 days of Uptime running v4.5.4 I just built a new, larger server with a Pro license and used 4.5.6 ... so far it seems very stable (but it's only been about a week). I noticed in reviewing the various posts that there were several "whoops" in the releases over the past year -- 4.5.3; 4.5.5; and the abortive 4.5.7 & 4.5.8 releases. I just want this to be a "use-it-and-forget" box ... rarely (if ever) upgrading it except for failed disks [i've already got it fully populated] => so I want to use the most rock-solid release available. I also plan to build one more virtually identical box in the next few months. My SOLE purpose for these servers is storage -- the only add-in I need is UPS control ... so I've installed UnMenu and added the clean shutdown and APC UPS control packages. No need for anything more exotic -- but I want the most rock-solid, stable system I can get. The only "glitch" I've noted in 4.5.4 (which is also in 4.5.6) is the "too many files" error with Windows 7 when copying large numbers of files ... but this is easily fixed by adding the "ulimit -n 20000" line to ident.cfg (thanks to Joe L for this !!) With that change, these seem like VERY stable releases. Just interested in other opinions/experiences.

Ahh -- thanks !! One of these days I need to learn Linux (It's amazing how reliable this is -- I can't imagine going 140 days without rebooting a Windows box)

Joe, r.e. "... I'm envious of your uptime. " ==> Well RATS !! In the process of building this new server I did some stress testing (copying a BIG folder with thousands of files to the new server), and encountered a problem I had seen last year that I fixed with one of your suggestions on another thread [added "ulimit - n 20000" to ident.cfg]. It fixed it perfectly (again). HOWEVER ... in looking at my server it seems that line has "disappeared" from ident.cfg somewhere along the way !! I suspect it was when I last added a couple of drives -- UnRAID must have regenerated ident.cfg and I lost that extra line (Does this seem right?). In any event, the line was gone -- which means my server has the same problem. It's been 140 days since I added those drives -- so clearly this isn't an issue I encounter often (since I mainly am only copying a few large media files) ==> but it means I have to REBOOT my server ... & start over on the "uptime" count :)

Thanks -- works like a charm now