But with traditional HDDs, the amount of engineering and domain-specific knowledge to manufacture and assemble the platters, moving heads, casing, etc, is such that there are only a handful of companies around the world who can do this (Seagate, WDC, Hitachi, etc). They have decades of experience doing that, so the firmware part of HDDs happen to be very robust as these companies have seen everything that can and will go wrong in an HDD.
So it boils down to this: which would you trust more, an HDD firmware code base that is 20 years old, or an SSD firmware code base that is 4 years old?
Combine this with the fact SSD firmware is much more complex (a flash translation layer must minimize write amplification, do wear leveling, spread writes on multiple chips, etc), and you are guaranteed that many SSDs on the market are going to be very buggy.
I think we're a few more years of shaking out this industry and leaving behind all the growing pains. No idea who will be left standing, but I suspect Intel will probably be around.
(Apparently the drive really didn’t like being issued with an 'hdparm --security-set-pass X /dev/sdb' command. I was intending to do a secure wipe, for which the password setting is a pre-requisite, but the drive never came back from setting the password. After that it just returned junk data to any command, including 'hdparm -I /dev/sdb' & failed the power-on BIOS SMART test.)
I don't know if this only affects the SATA SSDs or not, but it happens a lot. (BTW, the random disappearing also affects some other SSDs from other brands.)
Intel's in-house designs have an extremely good track record. I'm only aware of two major bugs.
There used to be something like one hundred car manufacturers in the USA, around a century ago!
Another way to look at oligopolies is they no longer need to compete on quality or specs if they slack in unison, and the collapse and commodification of their product means they'll get nickel and dimed to death so I wouldn't expect perfection from them, they find ways to screw up. You can't "wish" or "push" commodity status on a market if mother nature and the economy in general prevent it from happening, forcing commodity style management onto a non-commodity product/market just makes a mess.
Something _horrible_ happened on the 3TB Seagate batch. 4TB and 2TB are reasonable... but 3TB... wtf happened?
Manufacturers could then eventually converge all of their development and QA efforts on a few different codebases designed for different tradeoffs rather than everybody rolling their own thing and learning everybody else's lessons the hard way.
But I guess as long as custom firmware remains a major competitive advantage, this would never happen.
Do you have intimate knowledge of the firmware writing process for hard drive manufacturing? Do you think knobs aren't twisted and codebases aren't rewritten to take into account the changes required for the latest in magnetic storage? Geometry calculations for perpendicular and shingled media is less complicated than a flash translation layer? Also just because something is old and hasn't broken yet, doesn't mean it's well written, bug free or will work in the future. This isn't to say that hard drives are reliable, as they're notoriously the least reliable thing in your computer.
If you take the platters out of one hard disk and put it into another hard disk with different firmware, the other hard disk PCB won't be able to read it or write to it. I found this out by having a dead Hitachi drive (yes, the IBM "Deathstar" disks after they were sold to Hitachi) so I bought another identical drive and swapped PCBs but on startup the read/write head would not settle as there was a mismatch between the PCB firmware number and the firmware identifier written on the start of the disk. So, although I thought they were identical disks they were not.
Also, RAID6 is a bad idea, almost as bad as RAID5. There have been numerous studies and reports  indicating that both are very susceptible to subtle bit errors ("cosmic rays"), and this is made even worse when SSDs are involved. If you need absolute data integrity, RAID1 is your only option; if you need a balance between integrity, performance, and capacity, go with RAID10, which is still leaps-and-bounds better than RAID5/6.
> Mirrors are ideal, but it is hard to justify the upfront cost.
The upfront cost of redundant backups can also be high, but that doesn't mean one should forego them (unless their data isn't worth it, in which case, why bother collecting it?).
Going cheap on things is fine in the home computing realm, but once you're in the business realm, going cheap almost inevitably becomes more expensive in the long run.
Raid 5/6 are still not appropriate for todays large disk sizes, but raidz3 (three parity disks instead of one or two) is.
This is part of the reason why ZFS supports a variety of different RAID and RAIDlike configurations. If you're using a pure-ZFS approach, I'd strongly recommend having zpool create striped mirrors (i.e. RAID10) in order to get the benefits of ZFS' data checksumming and not be susceptible to such a high risk of data loss.
This appears to apply to all the consumer-grade Crucial drives.
See , money quote:
"In the MX100 review, I was still under the impression that there was full power-loss protection in the drive, but my impression was wrong. The client-level implementation only guarantees that data-at-rest is protected, meaning that any in-flight data will be lost, including the user data in the DRAM buffer. In other words the M500, M550 and MX100 do not have power-loss protection -- what they have is circuitry that protects against corruption of existing data in the case of a power-loss."
People don't expect files they haven't saved to be written and magically come back later if the power goes out, but they do expect that their drives will power back up with all the data that was last written intact.
However, Crucial explicitly marketed their SSDs as having, quote, "power loss protection", pointing out the array of capacitors on the drive's PCB, and strongly implying that this feature included in-flight writes surviving a power loss (i.e., that the caps had enough capacity to enable flushing the DRAM buffer to the NAND media, much like the non Sandforce-based Intel SSDs — e.g., the 320 series from a few years back, or the current DC-3500 and -3700 drives).
That, it turns out, isn't true.
And that's a problem, because I and many others bought these drives on the basis of Crucial's implying they were power-loss durable. When enough people started reporting to Crucial support that their drives didn't, in point of actual fact, offer this feature, their marketing literature changed so as not to imply they did, and forum posts and reviews, like my previously-linked Anand Tech article, started pointing out that they didn't.
Putting that stuff in the OS puts you back to, oh, the same wicked stuff that people had to deal with for MFM hard drives (remember cylinder, head and sector counts? Only probably ten times more complicated).
A block level abstraction is fine, as long as the abstraction can make some transactional guarantees.
That being said, if you build your system correctly, there is not any extra CPU load created by maintaining the FTL at app level. The main problem is the lack of an API for wear detection. I have discussed this with senior chip designers at the major manufacturers, and they are all loath to nail down to one api, as they believe how wear is specified will have to change over time. That's a broad brush - some manufacturers are more open to these discussions than others.
I'm still working on them.
I'm not so versed in the area so I'm just blind guessing here.
This kind of thing tends to be quasi-cyclic.
At one time, desktop computers had separate FPUs. Over time, those got integrated onto the main CPU, but then the trend switched back, with heavy calculations moving off-CPU to the GPU.
The mainframe->desktop->cloud story is similar.
I say "quasi"-cyclic because (e.g.) cloud isn't really the same as mainframe, but the transition back and forth between centralized and decentralized is still striking nonetheless.
Keep an eye on the AMD APUs moving forward and their HSA progress.
PCIe SSD devices, though, already feature an advanced controller (that is, a CPU core). This core could be programmed from the "computer" side somehow — but building any public API is always a major commitment, and takes much more effort than a proprietary API which you can change at will.
Right now the SATA interface prevents anything like that from happening, and the market has already moved to these proprietary broken controllers with braindead GL-class protocols to access them. (SATA, NVMe)
You're asking for a hardware interface of unprecedented complexity and cross-platform vendor neutral drivers of comparable complexity to 3d graphics drivers, all for the sake of letting SSDs have "dumb" controllers for a generation or two before the technology changes enough that the controllers need to start translating things again.
* Don't use hardware RAID controllers.
* Don't buy hardware from people who are going to change SKUs out from under you, or worse, change what's actually delivered for a given SKU.
Call me a huge cynic if you must, but given the other problems observed, I think there's a really simple explanation for perfectly uniform "99% health" after three years of service that doesn't involve "you get what you pay for."
An SSD at 85% wearout will take longer to program and erase the blocks and it will require more refreshes (data retention suffers) so there will be considerably more background operations.
In fact SSD vendors do quite a bit to make the disk perform its best early on when they absolutely can and then start to break down further down the road after the benchmark is over. After all the users are mostly only testing it for a month or two and they never get to a real wearout condition during the test and then they buy in bulk and run it for a few years but by that time the SSD model is already outdated anyway (about 18 month cycle for SSD models).
SSDs have a fairly consistent failure curve (exusing firmware bugs and other random events) for a given model, so they'll wear evenly in a raid setup. This means they'll all die at the same time as writes/reads are distributed fairly evenly across the disks. Given the size of today's drives, you may not complete a rebuild before losing another disk.
Has this been proven to not be true within the past few years? I don't run redundant raid on ssds. It's either raid0 or jbod.
That said, most of the drives in this article are consumer drives. The problem with consumer drives is that they don't have capacitors. And since your writes are cached by the drive before they go to the NAND, if you lose power all of your drives will be corrupted in the exact same way at the exact same time.
If you don't care about the data, go ahead and use them. If you do pay the extra for Enterprise drives. They really aren't _that_ much more expensive these days.
I'm genuinely interested.
We have only had two Intel drives die on us. I'm interested (well academically, not professionally) if they will die at the same time or keep dropping off one at a time.
We tend to retire the machines or the drives in them before they fail.
In general, thermals tend to be a significant issue for all form factors when devices are retrofitted. Less so for 'products' (All flash arrays etc.) which are designed as whole products from the outset.
This creates a failure pattern that is totally separate from predictable wear due to use and means that 'they'll all die at the same time' becomes much less certain for some categories of device.
Also, there's the controllers, which tend to be a significant source for issues.
So yeah, maybe theoretically, the wear out would be a concern for raid. However, practically this is rarely an issue as other failures randomize the distribution enough to where this never causes a problem in-situ.
The 850 pro is ok, but it's slowed down a lot lately. Might be an OS thing, which i doubt.
All in all i keep a redundant backup on old school hdds too since the failure rate of SSDs isn't so great in my experiences so far.
Anyone try one of the newer M2's yet? Or i think i mean the pci-E types?