Biggest takeaway was at the end, with the "enterprise" drives being slightly less reliable than the consumer ones at half the cost.
The concrete features I understand "enterprise" drives as having are:
1) firmware is built with RAID in mind. This might sound weird, but consumer drives are more likely to have problems with RAID, just because they aren't designed for it. See, for example, the first WD Green drives crashing RAID clusters because some timeout was too high.
2) Longer warranty period
3) This may not be true anymore, but I believe they typically feature larger cache
4) ECC
[1]: http://www.pantz.org/hardware/disks/what_makes_a_hard_drive_...
As for the RAID point, you'd very much want to find real data for that. I've heard similar folklore but have also heard plenty of lost data stories from enterprise disks in enterprise RAID. If I were building out a large storage farm, I'd strongly consider forgoing hardware RAID altogether and using something like ZFS so it'd be observable.
If you've ever worked with enterprise RAID, that should not surprise you! RAID is powerful, but also so easy to botch...
The second takeaway is: Check the last Backblaze report right before you buy new drives.
/HGST employee
It is so bad even running HD video off of some 2014 HGST laptop hard drives causes distortion. There's also no way to increase the ADM value indefinitely that I am aware of (it reverts after every sleep).
For those not "in the know" the hardware is the same, but desktop firmware drives will sit there for 10 seconds or whatever it is beating the drive when there's a read (or write) fail on the assumption that if your machine only has one drive you're better off trying as hard as possible to keep retrying until it works, and possibly the slowness will motivate them to replace (god forbid an end user have backups lol)
Enterprise firmware, when it has a soft fail, just croaks as fast as possible. That lets the raid array hurry up and do its thing, or maybe even higher level replication do its thing.
(edited to add the old startup adage of "fail quickly". Thats what enterprise drives do to keep overall array latency low, which is counter productive for consumer non-array drives)
Aside from the firmware load the prices are different because usually enterprise has better guarantee and better service and unlike consumer drives which statistically are never replaced under guarantee so you can claim anything on paper for marketing purposes it won't cost anything, enterprise drives WILL get replaced and there will be a papertrail etc. So the guarantee for an enterprise drive actually costs something.
Sometimes the firmware has some other subtle differences like how it handles recalibrates and scrubs (consumer home drives are like "too bad you get to wait on my schedule" and again, enterprise will go to some effort to eliminate array latency)
My guess is the article is subtle astroturf by the winning drive mfgr?
I imagine someone in the drive / enterprise storage business would know better, but many of us might not have known that.
Oh I should preface my remarks with "in family, same technology level" etc.
I'm talking about the same package with the same storage where different firmwares are loaded. Thats the business model the OP is in, he makes posts about stripping consumer drives out of external cases and I don't want to speak for him but he radiates the impression of their whole secret sauce being reliability at the system level not the hardware level.
It is true in my experience that "exotic hardware" marketed as enterprise grade is different physical hardware and is going to be a different level of reliability than consumer hardware.
So the difference between an office NAS SATA 1 TB enterprise and consumer grade is a firmware load, and I think thats what the article is talking about. There is a big difference between a 15K SAS enterprise server drive and a 7200 SATA consumer drive at the hardware level, but that's not the article author's "thing".
They're never replaced because regular consumers statistically don't ask for replacement and simply eat the loss?
At a business that is probably some MBA metric and has been budgeted for and is salaried anyway, and you need to prove I'm not just taking drives home to put in my basement server, so they have to be destroyed or sent back, and there may or may not be PCI / CPNI type concerns, so yeah, they get sent back.
drives with longer warranties generally cost more in the consumer segment, and data like this could help people identify the "sweet spot" balancing cost with risk of failure, warranty length, and depreciation curves for storage. my "ancedata" suggests somewhere between 2 and 3 year warranties seems about right for consumer drives these days...
There is another paradox as well. Some people won't ask for replacement because assuming you have to send in the bricked drive there is the chance that someone might get at your data somehow.
What about that? (It's why I would never send in a drive that has failed.) [1]
[1] My assumption is that I would have to send in the bad drive (and there is no way to reformat or for me to easily destroy what might be on there). Anyone have experience with what happens here?
So for example you might want to encrypt something super sensitive (which I do) but decide to not encrypt something less sensitive (say photos or perhaps a wiki with notes or letters to your grandma or wife or sig other).
Point being that if the drive isn't encrypted you might be able to get at some of that data. (If you need to). If you've encrypted the drive then can you still do that?
I strongly recommend Tarsnap[1] for that. All your data is encrypted before it leaves your machine, it is run by our very own 'cperciva, and the key used for encryption (which you need to store securely somewhere, like your parents' house or a bank) can even be printed so hard to destroy accidentally.
The key itself can be encrypted, too. You can use the same password you use to encrypt the drive and now you safely and securely store all your data in such a way that only you can ever access it by remembering a single, longer phrase.
(Although to be fair, another backup would probably be a good idea if the data is really important. Maybe another encrypted hard drive kept at work.)
I'd like to see on sites like that some kind of continuity plan.
Unless you are suggestion that this is just another "redundant array of backups that you have to assume can fail".
But even in that case it would be a good idea if cperciva had something posted on the site which showed there was someone else who had access and kept on top of the system.
Because now I have a problem: should I believe guys who have been running 38 petabytes of storage for several years now and regularly present the data they gathered, or should I believe you?
I am open to the idea I'm misinterpreting how he presents enterprise vs consumer firmware loads. I assume its open knowledge that their secret sauce is using consumer hardware so assumptions about 15K fibre channel isn't relevant.
Can you respond to this directly, please?
o Enterprise and Consumer Drives are the Same Hardware.
o Enterprise Firmware causes the drive to fail fast on physical errors
rather than endlessly retrying.
o Enterprise Drives are more likely to be RMA'd?
http://features.techworld.com/storage/1019/what-is-time-limi...
TLER is exactly what you want in a RAID. You have another copy of the data in question on the array, why fight for it on a disk when the data may be corrupt anyway.
What I'm interesting in hearing, (honestly - I not doubting right now, just interested in being educated) - is if anyone authoritative has described "Enterprise" drives as having these behaviors.
Except that also only works "most of the time".
Anyone who works at scale with drives and (RAID-)Controllers knows that even "enterprise" drives can and do take entire controllers down.
It's not uncommon to lose a full set of daisy chained JBODs to a single disk acting funny.
Consequently, and since storage clusters have to be redundant at the node-level anyway, it makes a lot of sense to skip the markup for enterprise firmwares and instead design for quick node failure detection and ejection (short timeouts).
Disclaimer: HGST employee.
I'll leave this non-HGST (Intel) link (PDF) for reference:
http://download.intel.com/support/motherboards/server/sb/ent...