garycase

As I noted above, the Vortex is a VERY good choice, and provides much better cooling than the 5-in-3 units that have smaller fans "pulling" air from the rear. My Vortex units keeps drives about 6-8 degrees cooler than my Icy Dock 5-in-3 cages.

The A79 is a typical "fans in front" case, where the fans are "inside" the case and need to be removed if, for example, you want to use 5-in-3 hotswap cages. With the A80 you can use these cages and still have the larger, higher airflow, 140mm fans blowing air directly into the cages, which greatly enhances the cooling capabilities. When I had an A80 here (while I was building a system for a friend a couple years ago), the difference in temps between just using the 5-in-3 cage fans and closing the door was about 6-8 degrees on a parity check. I've NEVER seen any cooling combination that did as well as that case. It's a real shame it's no longer available. I've actually thought about building a small "tower" with 3 140mm fans that I could set in front of any system I want to provide roughly the same degree of extra airflow [wouldn't be as good, however, since there would be a path around the edges for air to "escape".].

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

It would indeed save SOME of the reformatting, but assuming you're not replacing ALL of your drives with the two new 4TB drives, you'd still have to reformat any drives that you were planning to leave in the array after you moved the data off of them. But if you have the ports to do it, it would save the initial rebuild of one drive that would later have to be reformatted.

Note these are two different processes. To replace a smaller drive with a 4TB drive is straightforward -- but the resulting 4TB drive will have the SAME format as the drive it replaced (e.g. RFS). I'd replace ONE of your smaller drives with a 4TB drive; then move as much data as possible to that drive from other smaller drives (emptying some of those drives). Then I'd do a parity check to be sure all is good; and then I'd do a New Config removing all of the empty drives and adding the other 4TB drive. After the parity sync for the new config completes, do another parity check to confirm all went well. Then change the format of the new (and EMPTY) 4TB drive to XFS; then copy all of the data from the 1st 4TB drive to the XFS drive (verifying that it is a good copy); and then you can format the 1st drive to XFS (this will delete all the data on it -- but you just copied it to your other drive, so it's okay). Now you'll have an empty 4TB drive in XFS format, so you can move all the data from a smaller RFS drive to it; then reformat the RFS drive to XFS; and then repeat that process until you've got all XFS drives. VERY IMPORTANT NOTE: Be CERTAIN you understand the "user share copy bug" and do NOT copy in a way that will cause that issue -- if you do, you'll lose ALL of the data associated with that copy.

Basically the only time my servers are ever shut down or rebooted are (a) extended power outages that last longer than the 10 minutes I have the UPS control software set for (rare); (b) software updates that require a reboot (the most common reason); or (c) hardware changes (adding/replacing a disk drive -- also fairly rare). It would be easy to get a year or longer of runtime (been there/done that) ... but it's not something I focus on. Basically I reboot whenever there's a new stable release (I have a test server for the pre-releases).

I had a v5 server with over a year of uptime ... the only reason that streak ended was a power failure that exceeded the UPS timer I had set, so the system shut down. I agree, however, that with the much more frequent updates (and much simpler update process) with v6, you really don't want to go over a year without updating, as many of the updates are designed to improve security.

Good shot => hopefully that will help anyone who's trying to do the same thing. It's a shame that's not simply "designed in" to this case -- it makes a BIG difference in the airflow across the drives; and makes it a really good case with that modification.

"OP" almost universally means Original Poster -- i.e. in this case it would be a reference to dlandon. A reference to the first post in the thread should simply be that ... e.g. instead of "... Check the links in the OP for ..." it would be clearer to simply say "Check the links in the first post ..."

Danioj did a great job of "skirting" the drive cage so airflow is forced through the hard drives (without the "skirt" it can bypass the drives and go directly to the motherboard area. I can't find his detailed description of this mod, but did find a later post where he provided the detailed dimensions of the "skirts" he used: If you want more detail, I suspect if you send him a PM he'll provide a link to his original thread on his backup server where he outlined the modification in more detail [If so, please post the link here so I can add it to my bookmarks and won't have to search for it again the next time somebody asks ]

A standard G4560 has a TDP of 54w, vs. 35w for the "T" version. So on a highly-intensive operation that occupies 100% of the CPU it's going to draw 19w more than the "T" version would. While it's true this will allow the operation to finish somewhat earlier than with the lower-power version of the CPU, it's not likely to be a significantly shorter time, due to the I/O requirements, which aren't impacted by the speed of the CPU. So I do NOT think this is a linear function. Note that modern disk drives are far more power-efficient than previous drives -- a 4TB WD Red for example only draws 3.3w when idle (4.5 during I/O -- but the total amount of I/O would be the same regardless of the processor; so any "extra" time waiting for processing it will be idle). So you have a CPU drawing 19w more for slightly less time vs. a disk drive drawing 3.3w more for a small amount of time. Clearly which scenario would actually use more power depends on how many drives are spinning and just what the time differences are; but I very much doubt it's a significant difference in either case. And note that if the transcoding is for a Plex stream there's (a) likely only one disk involved; and (b) the disk is probably spinning for the entire stream anyway, since it's steaming a video at "watching speed" -- not at the minimum time it can transcode it. Nevertheless, as I noted earlier, I'd go with the higher speed CPU anyway -- it's always nice to have a bit of extra "horsepower"

Agree the limited power versions of the CPU aren't necessary. Don't agree that they would actually INCREASE the overall power for tasks, but nevertheless it's true that you'll RARELY exceed the power limits of the "T" version anyway, as the standard CPU is very unlikely to draw that much in normal UnRAID usage. And it's true that if you DO need the power, it's nice to simply have it available. As for the stock cooler => Yes, it fits fine in the ITX cases; and provides plenty of cooling for the CPU.

I rarely get to the Atlanta area, but next time I'm there I wanna play !!

Paul => NEAT hobby !! I watched the partial interview in your blog and was really looking forward to the details of the "innards" ... but the interview ended (i.e. camera ran out of storage) just as you took it apart) There was enough to get a good idea of the complexity of the project, however. Good luck with finishing your Black Knight in time for this year's expo. Did you ever market your own "pinball construction kit" that you referred to in the blog ??

NFS won't have the freeze issue IF you're seeing it due to SMB waiting for another drive to spin up. But if you have a controller that causes the issue while another drive on the same controller is spinning up then the network protocol in use really won't matter.

Agree (as I noted earlier, not all controllers have this issue). It takes a good bit of experimentation to confirm this; but you only need to do that once. I did it a long time ago for my media server (5-6 years ago); and it's now completely "glitch free" for all media streams. As noted above, another way to resolve this is to simply leave all of the disks spinning.

It's not an issue of how much music you have -- it's a function of if you have two shares on different disks that happen to be on the same controller and that controller has the "stall while drives are spinning up" characteristic. Suppose you have all your movies on one disk; all you music on another. Someone in the house is watching a movie; and you decide to play some music. When you start the music, the disk with your music share needs to spin up -- and this could cause the movie to "freeze" while that disk was spinning up. [The opposite could also be true -- if somebody was listening to music and then a movie was started the music would stop for a few seconds.] This is what spin-up groups can prevent.

Actually it doesn't matter if you have an array of 10TB disks => if two disks are on a controller that will "stall" access while spinning up a connected drive, then putting them in the same spinup group will eliminate a "freeze" in a movie being streamed off of one of the disks when some action on the server results in the other drive spinning up. I think most of us have all files associated with any given video or music album on the same disk, but what a spinup group will do is eliminate a "freeze" in what's being streamed from a disk if another disk on the same controller is spinning up. Doesn't matter if there's any content for the share on that 2nd disk -- if it's on a controller that will "stall" all access while a drive is spinning up, then putting the drives connected to that controller in the same spinup group will eliminate this issue. If you keep all your drives spinning; or if you don't have multiple users using the server whereby a drive might need to spin up while some other drive on the same controller is streaming a video to another user (or if your controller doesn't have this issue); then spin-up groups aren't needed for your situation. But anyone who has a controller that exhibits that behavior can definitely benefit from them.

These are superb units. The front-mounted 120mm fan provides EXCELLENT ventilation ( the drives run much cooler than they do in units that have offset rear-mounted 60 or 80mm fans). The lights can indeed be disabled -- there's a small slide switch to do just that.

Agree -- any modern disk is easily fast enough that an active movie stream at the same time as a write is NOT going to cause any issues with the stream. As Squid noted, you can easily see this by streaming a movie during a parity check. In fact, just stream a movie from a disk you're writing to in normal read/modify/write mode -- which has twice as many disk I/O's as turbo write, so would be even more likely to cause an issue ... and even that almost certainly won't cause any problems.

Yes, that's what I recall as well. Just can't seem to find the thread where it was discussed.

?? Note that the "auto" setting is for a parameter called "md_write_method" ... there's no "enabled" or "disabled" values for that => it's either "read/modify/write" or "reconstruct write" (the latter is what's referred to as "turbo write"). ... but even if the choices were "enabled" or "disabled", it's very counter-intuitive to have an "auto" setting unless it's enabling/disabling based on some state of the system. There's NO reason to have a setting called "auto" unless it's actually making some kind of choice -- and the only choice that makes any sense with regards to this setting would be to use reconstruct write if all the disks are spinning; or the read/modify/write method otherwise. I don't recall the specific thread, but this has been discussed before, and my understanding was the ultimately that's what it was intended to do.

Based on discussions in another thread, I'm fairly sure that's what the "auto" setting for md_write_method => it's actually the default setting; but isn't really implemented -- it simply defaults to the standard write method at the moment. But a plug-in to do it NOW is indeed nice. Regardless of which way it's implemented (plugin or "auto"), the nice thing about that is you then don't have to change the setting to use turbo-write for large data transfers ... just click on "Spin Up" and the system will automatically use turbo write ... and once the drives are spun down writes will revert to the normal method.

I can't think of any reason not to use it in this case -- I think that's what the "auto" setting will (when implemented) do. I agree I wouldn't spin drives up to use turbo write for just a few writes, but certainly if they were already spinning it'd be nice if the system would use the faster write method if it didn't cause any additional spinups.