garycase

You clearly have not seen a Q08 ... when I noted it required "... the removal of 6 tiny screws to remove a panel ..." perhaps I should have said it required " ... the removal of 6 tiny screws to remove a panel." 8)

Yes, I indeed meant what I said (i.e. PMR) It wouldn't even require higher density platters => HGST already has a helium-filled 8TB PMR drive using seven 1.2TB platters. Achieving that density without helium may be a challenge ... but it may also be possible to improve the platter density to 1.35TB and get 8TB with only 6 platters. Hard to say just what technological advances might happen in the near term ... but it's pretty clear there will be some !!

Good to know. I'm actually still on the fence ... plan to build a new server in Nov/Dec after a couple trips we're doing before then. My original thought was to use 8TB SMR's, but I'm waffling a bit on that -- and if I stay with PMR's I may still go with the 6TB Reds ... I DO trust WD to not release a drive that can't be reliable [but I also know that 1TB platters are "pushing" the density less than 1.2TB platters ]. On the other hand, densities have been improved for years, so all is likely just fine with the 6TB units. Who knows, by Nov WD may release an 8TB PMR Red

Interesting experience. The 8TB SMR's seem to be doing very well r.e. reliability, but not so much for the 5TB versions. In any event, for 5TB drives I'd use either Toshiba or WD Reds anyway, to stay with PMR technology. I've got one of the 8TB Seagates (not in UnRAID) and it's working very well as an extra storage drive [on my main PC]. I keep large files there ... images of my other PC's, ISO's of all the various program CDs/DVDs I've collected over the years; etc. Much of this is also on my UnRAID server, but it's convenient to have it locally available. (and you can never have too many backups ) But for additional drives, I'm beginning to learn towards 5TB Reds for my next UnRAID box. I'm happy with the 8TB SMR Seagate, but not with Seagate in general, as I've seen more issues reported in the last few months than I like. And there have been a few folks with issues with WD's 6TB Reds ... which are likely due to the "push" to 1.2TB platters [the 5TB Red is essentially the same drive with 1TB platters, which have proven VERY reliable in all the other Reds).

I think even later SATA controllers have this issue -- not sure what the exact relationship is between the various channels, but they can definitely still exhibit this behavior. I can see both the SMB issue and the controller-related issue by starting a large copy from one drive; then starting another copy on the same PC from another drive that's not spun up ... the first copy will "hang" for a few seconds until the 2nd one starts. [sMB issue] If the 2nd copy is done from another PC, then whether or not the first one hangs depends on WHICH disk I use as the source for the first copy. I haven't built an exhaustive "interaction spreadsheet" to know which drives have these interactions on my two newer servers (2.5 yr and 1 yr old) ... but did build one for my older CS2EE based server, and that's where I use the spin-up groups.

As I noted several times, the issue is interaction within the controller -- NOT the Windows connection. You get this behavior even if you're accessing the array from multiple clients (each with their own SMB connection) ... and independent of what the client is [Windows, Linux, Apple]. If it's too complex to retain, so be it ... but it DOES resolve an issue that can be a bit of a nuisance (but not, in the great scheme of things, a big deal). One very simple way to bypass the issue entirely is to simply hit the "Spin Up" button whenever you're going to have multiple folks using the server ... and perhaps set the spin-down timer to a moderately long time (2-3 hours).

Agree with Bob => and like him I use spin-up groups, but can live without it. Simple fact is an occasional pause in a movie stream is simply no big deal.

No ... at least not in the instances I saw (both mine and others). The issue is that some controllers -- whether IDE or SATA -- will "hang" activity on one attached when other attached disks on the same controller channel or group are being spun up. Has nothing to do with whether or not the other disk is on the same share - or even if the access is from the same client. Say, for example, that the wife/kids are streaming a movie from Disk 3, and you decide to copy a file (pictures, a document, a spreadsheet, or whatever) from Disk 5, which isn't currently spun up. On many controllers, spinning up Disk 5 won't have any impact on Disk 3 ... but on some it will cause Disk 3 to hang while Disk 5 is spinning up. If you have this kind of interaction between disks, you can eliminate the problem by putting them in a spin-up group, so whenever Disk 3 is spun up, Disk 5 is also, so that any access to Disk 5 isn't going to cause an issue with anything currently being streamed/copied from Disk 3. Note that this isn't a Windows issue, Mac issue, or whatever ... what OS the client is using is irrelevant ... it's caused by the controller. You could, of course, if you know you have media that spans multiple disks, use spin-up groups to do as you noted -- prevent a delay while the next disk is spun up. But that issue is easily avoided by using the correct split level for your shares. And this issue has nothing to do with the controller -- it's simply due to the need to spin up another disk.

One of the nicest features of UnRAID is the user shares, which allow multiple disks to be seamlessly combined into a large storage unit without user involvement. While I understand that some like to "balance" their data, this is NOT necessary and somewhat defeats the "seamless-ness" of the user shares. It does make sense to use split level settings that maintain all components of a particular media element together (i.e. if you're storing DVDs in their original .VOB's, you want all VOB's for a particular DVD together) ... but even that isn't necessary except to eliminate a spin-up requirement when switching between VOB's. Further, even if the data is "balanced", spin-up groups are still useful => the issue isn't that they prevent the need to spin up another disk associated with the currently streaming bit of media; it's that there's an interaction between disks on the same controller channel (or even the same controller) such that when you're spinning up a disk on that controller, all activity on other disks on the same unit is suspended during the spin-up. If you have disks that exhibit that interaction, you can use a spin-up group so that when any disk in that group spins up, all the others do as well, so any subsequent use of one of the other disks won't impact your current media steam/copy operation/write activity/etc.

Might be to you, but I use them quite a bit. So, not useless. Ditto ... these are definitely useful.

I'd agree with "not change a thing", as Bob's experience isn't by any means unique. Note that replacing it with a share-based spinup option doesn't resolve this, as the pauses/stuttering that are often seen aren't necessarily due to accesses within the same share -- but by an access to a disk that is on the same controller that needs to be spun up. This is NOT (as I noted earlier) restricted to IDE controllers ... it's not an uncommon behavior with SATA controllers as well.

You can already do that somewhat by assigning your own spin-up group(s) and having your media isolated by type. Yep, and if spin up groups as they are defined now are removed, then having the OPTION to turn on a user share group spin up would replace that function. I never suggested that spinning up all drives in a share would be a default setting. That option would be okay if it's a "by share" setting ... but I don't see it as an improvement over the spin-up groups that are implemented now. The key reason for spin-up groups was to prevent pauses/stuttering in a stream if a drive on the same controller channel was accessed and had to spin up -- not necessarily that the other drive was part of the album/movie that was streaming (although it could of course be used for that purpose, as Squid did). Note that this can also happen with some SATA controllers, so there are still cases where it's useful. My "vote" would be to keep the current feature ... but as I noted earlier I don't really care either way.

I use them, but don't really care if they're eliminated. I have a couple backup shares that, when I'm using them, I do so fairly aggressively, so I have all of the disks in that share assigned to the same spin-up group. On the other hand, I would NOT want a "share-based" spinup (as suggested above), as all of my media shares are unrestricted WRT which drives they can use (except for the drives associated with the backup shares, which I exclude from media shares). I would not, for example, want 18 drives to spinup whenever I access my DVD's share

... sounds like a CAREFUL job for a Dremel

Just noticed this comment and am curious about exactly what the issue is. I'm thinking of ordering the U-NAS case, but am not sure what adapter you're referring to.

Don't know about the UDMA CRC errors, but wouldn't worry about them -- the value for the parameter is still 200, which is "perfect", so it's clearly not an issue. Seagate reports all of the raw errors (WD does not), so you see all of the corrected sectors reported -- the Raw Read Errors -- along with the fact that they were all just fine after ECC -- the Hardware_ECC_Recovered.

Let us know the results (I'm sure you will). The "buffer area" is called a "persistent cache". From what I've read about these drives, the 5TB unit has a smaller persistent cache than the 8TB drives, so that may also have impacted what you were doing earlier. Assuming the drive "passes" your pre-clear testing, it should work very well as an effectively "read only" array drive.

That is a VERY nice-looking case!! Definitely going to look into that one

Very nice looking case => looks like you got the new backplane and fans, which is a very nice improvement.

When I built my backup server a year or so ago, I did a massive TeraCopy from my media server (24TB) and another pretty large one (~ 11TB) from my backup server. Both worked just fine. The only difference from what you noted is that these were copies with verification -- not moves. Was there anything "special" about the moves you were doing -- i.e. were they restricted to a specific disk? [still hard to see how that would cause a red-ball, but it's equally hard to see how TeraCopy could be responsible for this either.]

Not sure how many bytes it takes to cache a single file entry in the directory, but I'd assume it's not more than 256 bytes. At 256 bytes/entry, that's 4 entries per k; 4,000 per MB, and 4,000,000 per GB. I doubt many of us have 4 million files on our servers ... so a GB should be VERY adequate for caching the entire directory structure. Even at 1k/entry you could still cache a million files in a GB.

:) That would indeed be an excellent choice (and indeed is what I'd use), but for what you've described I suspect you'd be quite happy with an i5 for ~ $100 less. An i5-4570, 4590, 4670, or 4690 would all be good choices. I think it's unlikely you'll find an i5-4570 at the price spencers found it, but if you do, that's clearly a GREAT price. Barring a find like that, they're all fairly close in price, so just buy whichever one you can get a good deal on. [Or just bite the bullet and pick up an i7-4790 ] ... never heard anybody complain about having "too much" CPU power ... FWIW I readily admit I've "wasted" $100-200 on each of the personal system's I've built in the past couple years (wife's, 2 HTPC's, spare system for guest room) by using the i7's ... I just use them "because I can" => and so if I ever want to repurpose them for anything they won't be underpowered In most cases, an i3-4330 would have been fine.

$100 in indeed an EXCELLENT price for that case !!

Perhaps use a green triangle on the shares page (as I noted before) in lieu of the yellow triangle. Cached shares would then get either a green triangle or a green circle; cache-only shares would always have the green triangle. The only difference is that the symbol that means "Some or all files are on unprotected storage" would be green instead of yellow .. but if that makes folks feel better, so be it

I've mentioned that several times -- the "fix" to not wanting to see an indication that there are some files unprotected is to simply add another cache drive and create a pool Then they'd never see the little yellow triangle at all 8) I also don't see why it would be disturbing to see it if you have an unprotected cache and some cache-only shares => in fact the state of those shares is that they're ALWAYS unprotected, so it would be abnormal if they didn't show that. Perhaps some folks aren't thinking about the fact this status is on a share-by-share basis. Also, it is NOT in any way an "error" condition ... it's simply an informative status indicating some data isn't fault-tolerant. For cache-only shares without a pool, that's always going to be the case; for cached shares, that will automatically change when they're moved to the array.