garycase

The Lian-Li PC-8000 is indeed a superb case for large (24 drive) systems => very easy to insert/remove drives without the need for hot-swap cages; and AMAZING airflow (you can put 6 120mm fans in front to blow air directly over the sides of the drives !! For small (7-drive max) systems it's hard to beat the Lian-Li PC-Q25B ... 5 hot-swap bays; a drive cage that holds 2 more; and a 140mm fan blowing directly over the drives. They make a couple really neat cases for 12-14 drive systems as well Basically, for non-rack-mounted builds, Lian-Li is the way to go. The only disadvantage relative to some of the other options is that they cost a bit more

I doubt Tom's going to aware an "ugliest UnRAID" title ==> but this should surely be a strong contender for the "most unique" build ... it actually looks pretty good !!

I don't see much (if any) advantage to USB v3 for UnRAID on virtualized systems. As already noted, it's simple to just use a virtual hard drive as the boot device in those cases -- with only the key file on the USB flash device -- so you can get very quick boots regardless of the USB speed. But on a bare metal system, where you'd need to dedicate an additional SATA port and space in the chassis for a boot drive, it would be much more attractive to have a USB 3 flash drive and USB 3 port to boot from. On the other hand, I almost never turn my UnRAID servers off, so it's almost irrelevant how long they take to boot [Although if they booted in just a few seconds, I'd likely turn them off a lot more]

Good point. Although as long as there's an available SATA port, an SSD can be mounted "creatively" in a lot of spare spots in most cases An excellent idea -- much better than using a dedicated drive. HOWEVER ... for many of us that would mean a new motherboard & CPU to get USB v3 ports (On some boards you could use an add-in card)

I thought that might be the case (I presume mrow will confirm). But the same thing -- probably even faster -- could be done by putting a spare SSD (I have a couple 40GB and 60GB units I don't use these days) in my UnRAID tower, and booting to those -- with just the key file on the USB flash drive Guess I just thought of a good project for next weekend !!

Are you referring to UnRAID's boot time? If so, how does it compare to bare metal boot times?

Joe, As you know, the "preclear_reports" folder on the UnRAID flash drive contain 3 files for each preclear that's been done: (1) preclear_start_<drive serial number>; preclear_rpt_<drive serial number>; and preclear_finish_<drive serial number> Am I missing anything if I simply look at the "preclear_rpt_<drive serial number>" file? For example, this is the contents of a recent one for one of my 3TB drives -- which shows only the temperature attribute changing (obviously a normal change), and all zeroes for the other items discussed above: ========================================================================1.13 == invoked as: ./preclear_disk.sh /dev/sde == WDC WD30EFRX-68AX9N0 WD-WMC1T0900350 == Disk /dev/sde has been successfully precleared == with a starting sector of 1 == Ran 1 cycle == == Using :Read block size = 8225280 Bytes == Last Cycle's Pre Read Time : 8:25:34 (98 MB/s) == Last Cycle's Zeroing time : 7:38:20 (109 MB/s) == Last Cycle's Post Read Time : 21:02:15 (39 MB/s) == Last Cycle's Total Time : 37:07:11 == == Total Elapsed Time 37:07:11 == == Disk Start Temperature: 29C == == Current Disk Temperature: 32C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sde /tmp/smart_finish_sde ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Temperature_Celsius = 118 121 0 ok 32 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ============================================================================

Joe -- Why is that a "No" I'd have thought "all zeroes" was the sign of a successful pre-clear operation. What else do we need to look for?

I've pre-cleared 5 3TB WD Reds with very similar times. All had "clean" reports at the end (all zeros). My pre-clear times for a single pass were ~ 36 hours (one was just under, the other 3 were a bit more. For 3 cycles they took about 85 hours -- very consistent with the results Bob posted. I suppose it's possible that a notably slower time (e.g. 45 hours) could be CPU-related; but I'd think it much more likely that it's due to a slower SATA controller or perhaps a poor quality SATA cable. My system is an Intel Atom (SuperMicro X7SPA-H-D525) -- not a particularly potent CPU (but a GREAT system -- draws 25w with the disks idle; a max of 45w with all 5 drives active (e.g. during a parity check) When I built this particular system a couple months ago (my 2nd UnRAID server), I did 3 passes of pre-clears on every drive (would have returned any that weren't all zeroes ... but fortunately they all were fine) => then did a parity check every day for a couple weeks (all clean). That was my "burn in". Really cool to see the system doing parity checks on only 45w of power !! [My older C2SEA-based system draws 175w when all the drives are spinning -- granted there are more drives (14)].

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]

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