Slashdot Mirror
How Intel and Micron May Finally Kill the Hard Disk Drive
itwbennett writes: For too long, it looked like SSD capacity would always lag well behind hard disk drives, which were pushing into the 6TB and 8TB territory while SSDs were primarily 256GB to 512GB. That seems to be ending. In September, Samsung announced a 3.2TB SSD drive. And during an investor webcast last week, Intel announced it will begin offering 3D NAND drives in the second half of next year as part of its joint flash venture with Micron. Meanwhile, hard drive technology has hit the wall in many ways. They can't really spin the drives faster than 7,200 RPM without increasing heat and the rate of failure. All hard drives have now is the capacity argument; speed is all gone. Oh, and price. We'll have to wait and see on that.
Well, the Samsung 3.2 TB drive claims that you can read/write the entire drive every day for five years before failure. It's my understanding that at one point, SSDs were notorious for gradually declining over time, but that today's generation of SSDs basically has reliability out the wazoo. I can't quote you stats on it, but anecdotally, I've had a couple of SSDs in my computer for several years now, I leave it on 24x7, and I've never had a problem.
...Yet. YMMV.
I don't know why Intel and Micron get any special consideration given that right in the summary the fact that Samsung has already announced the same move.
Also incorrect assertion that drives don't go faster than 7200 (there are 15k drives, just they are pointless for most with SSD caching strategies available).
XML is like violence. If it doesn't solve the problem, use more.
Actually, one of the nice things about SSDs is that as capacity increases, reliability increases too. More cells means more options for wear levelling, means more life span.
That's the thing. Most people who need 3.2 TB of space will only write to each location a few times, and data won't change very often. Sure, some writes will be happening, but not even close to the magnitude that you'd need to wear out one of these drives. There might be some cases in commercial applications where you'd need to write that every day, but the typical desktop or laptop is never going to see that kind of usage.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
And 15 years ago I bought a massive 2GB drive for $350.
Computer stuff gets cheaper over time. There's no reason the same won't be true for SSDs. At some point SSDs will be cheap enough that even if HDD are still 1/100th of the price, SSDs will still win because of all their other advantages.
In theory yes, in practice it's unlikely to ever come up. Wear leveling does wonders, over provisioning does more on top.
If SSDs had come first you'd be saying the same thing about HDDs: Don't HDDs have fragile mechanical parts that fail randomly?
SSDs will likely get there in 3-5 years by Moore's law. The question is where hard drives will be by then.
The price per GB on SSDs has been below $0.50 for some time now.
RAID doesn't protect against loss of data, that's what backup is for. RAID protects against loss of uptime.
It's not disingenuous at all. It merely demonstrates the primary problem here, namely the price gap. Larger SSD drives are low capacity and expensive. They are priced outside the range of most consumers while also being inferior in terms of bulk storage. A larger SSD is less able to justify it's price premium than a larger HDD.
Even if SSD prices get less ridiculous, chances are that HDD prices/capacity will keep pace and continue to keep HDDs relevant.
A Pirate and a Puritan look the same on a balance sheet.
Seems to me that I bought my first 85 MB HDD for about that much 30 or so years ago....
"I do not agree with what you say, but I will defend to the death your right to say it"
Also, didn't Intel exit the flash market a while back, spinning off its flash division along with ST Micro to Numonyx, which later got acquired by Micron? I thought that the whole idea then was that memory was so unprofitable that it wasn't worth keeping it as an albatross on corporate margins.
Also, memory fabs are different from the ones used for making processors/controllers - it's not like fabs that don't make more Atoms or Celerons will be repurposed for SSDs. So how does it make sense for Intel to get into this? Micron I can understand, since memory is their prime business. But Intel? It makes as much sense for them to be making this as to be in the DRAM market
We'll have to wait and see on that.
What's wrong with you people. We are waiting already for 5+ MORE THAN FIVE fucking years. Still hasn't happened.
1TB HDD - 60-80€, 1TB SSD - >350€.
The problem is that once PC is turned on, there is not much use for the SSD speed. It's not like I'm moving terabytes of data around everyday. And even if I have to, I do not have to wait for it: I simply leave it overnight.
Another problem is that (some) SSD have the nasty habit, once failed, to deny you access to the data at all. I hoped that at least those jackasses would straighten out the SMART support and finally standardize the monitoring parameters. But few moronic manufacturers even proclaimed that their drives are so good that they don't need no stinking SMART support...
All in all, SSDs are developing too fast. And have pretty bad history of firmware bugs. And literally all manufacturers, instead of strengthening their stance of data safety, all like one doubled down on the "oh but look how fast it is!"
P.S. And TRIM support is still in shambles. After all the years, some drives still require a proprietary application/driver installed.
All hope abandon ye who enter here.
All RAID levels protect against loss of data due to failure of individual drive(s), port(s), or data cable(s).
RAID 0 is not RAID.
RAID is not backup.
I've been using Seagate's hybrids for a couple years and the combination of performance, simplicity, and economy hit the spot. I have 750 gig and 1tb drives in my laptops and a 2tb in my gaming rig. The hybrid drives were a small price bump for a big performance bump. Sure, gigantic SSDs would give me a slight performance boost but it's a big jump in price for a small jump in performance over hybrid.
It doesn't matter what RAID level you use, rm -rf / will still dutifully delete all of your data for you.
Repeat after me, RAID is not a backup.
Game! - Where the stick is mightier than the sword!
Most current MLC (multi-level cell) implementations can sustain anywhere between 1000 and 3000 write/erase cycles per cell. This is better than TLC (triple-level cell, max 1000), but far worse than SLC (single-level cell, max 100k up to a million, depending on the technology).
The problem is the way how flash itself works, and how smart your controller is. Unlike a disk, flash must be erased before writing. And here is where the problem comes: flash data is stored in a page of cells, with typically 8 pages of data per "block". Erasing happens on the block level. So in order to erase a single page of data, you need to erase all 8 pages in a block. Since you need to keep the data of the other 7, you first need to copy that data into another block, erase the original one, write all data back and erase your "tmp" block. The churn on blocks happens a lot faster than what you'd think.
Having that said, for consumer products, MLC or TLC is perfectly fine. For enterprise, not so much.
You'll see that in the price, obviously. TLC is the cheapest, followed by MLC, and the most expensive technology is SLC.
I'm not a complete idiot... Some parts are missing.
Comment removed based on user account deletion
Well, the Samsung 3.2 TB drive claims that you can read/write the entire drive every day for five years before failure.
Such statistics are meaningless in my book. Light bulb manufacturers claim their bulbs will last five years or seven years but when you look at the fine print they say that's given under the idea you're turning the light on, leaving it running for 3 hours, and turning it off once per day -- nobody uses light bulbs like that.
Comment removed based on user account deletion
Comparing a $10 USB stick with an SSD is like comparing turtles to cheetahs. Those USB sticks might write at 2-5 megs/sec. Maybe. 1/100 the speed of a good SSD. It's not a cromulent comparison.
That may well be, but have you ever looked at a turtle's drag coefficient?
When our name is on the back of your car, we're behind you all the way!
You said: "The article writer mist be smoking some amazing shit to come to such a wacky claim."
Are you referring to the article summary, or one of the specificly linked articles? Because summary says: "Oh, and price. We'll have to wait and see on that."
So they are not making any claims about price. It seems maybe you are the one smoking too much?
Anyhow, there are only a few niche roles where a desktop needs that much space. Give me a 240 GB SSD with 10 times faster IOPs, 10th of the heat and power consumption, zero noise, and no moving parts. That's plenty.
HDD's still have there place for certain use cases, but SSDs beat them by an order of magnitude on just about every factor except price per gigabyte. $/gb is not as relevant when you realize $150 will get you enough of space on an SSD for most desktop roles, and way more than you need on an HDD.
So... I am using Smasung SSDs as a mirrored ZIL cache for a nas4free array hosting VMware servers and Horizon View desktops. In other words, mostly continuous writes 24/7. And yet I have one drive that failed (and was warranted) at just past one year, and the other drive is over 2 years old with no issues. Yeah, yeah, anecdotal, but a lot of enterprises are finding modern SSDs to outlast some spinning rust.
That said, the rest of the storage array is spinning rust for cost reasons. When you are talking about 15TB or more with parity, SSD is a little crippling to the wallet.
That's actually what they do.
1) Select an empty block.
2) Copy the data into ram on the device
3) Write the new physical block
4) Update the virtual/physical block map
5) Mark the old block as empty
Under common usage patterns, you can expect up to 25 years life for first-gen SLC, 15 years for first-gen MLC, 10 years for current-gen MLC, 5 years for current-gen TLC. MTBF is lower due to defective cells and such, but that's also true for HDDs.
Correct me if I'm wrong, but don't SSD's have a point where they put on too many write's per bit?
Tech Reportchecked a bunch of SSDs for write durability and virtually all of them made it to 600 terabytes of data writes or better.
For an ordinary desktop user, write durability is not a problem. Now what about storage durability? With 3 bits per cell, how long before the data fades?
You're both right. RAID can decrease the chances of data loss due to some kinds of problems, but ultimately it shouldn't be considered a reliable protection against data loss. A RAID can be lost or corrupted, or someone can overwrite or delete a file. If you want to assess the risk to your data and talk about the set of data that is protected against loss, you should only consider your backed up data to be "protected". The protection that RAID offers is too weak to be considered to be significant protection.
Therefore, the fundamental purpose of a RAID is to prevent the downtime due to failure of an individual hard drive. If you did not have RAID, then your data volume would stop running, and you'd have to be offline while you repair the device and restore from backups, so that's what you're successfully preventing. All the data that has been backed up (assuming your backup is good) should be safe, and any data that has not backed up is not safe, regardless of whether you have a RAID.
RAID is redundancy, not backup.
you first need to copy that data into another block, erase the original one, write all data back and erase your "tmp" block. The churn on blocks happens a lot faster than what you'd think.
If that's the case, then why are they not copying the data to ram contained on the drive itself? Seems like an awful waste of cycles with a relatively simple fix. Is it just a cost issue?
Any wear levelling worth its salt will not do what the grandparent wrote. You simply do not change one page in a block. If you write a single page, that is handled by mapping that page to another (free) block and maintaining a mapping table for which LBAs are currently stored in what blocks. However, if you are doing single-sector writes, or in turn repeated I/O flushes of the same sector, you still see a lot of write amplification. To keep data integrity, the mapping tables also need to be kept updated in a correct way (or at least uniquely recoverable by scanning through all blocks after a hard power off).
In 1987, I bought an 80 MEGAbyte drive for $775 (around $1600 today), thinking how amazing it was that disk drives had broken the $10/MB barrier. When the first 1GB drives came out a few years later, I remember thinking, "Who would trust that much data to a single device? What an amazing single point of failure!" Now there are 128GB MicroSD cards for under $1/GB. Even understanding the technology, the mind boggles.
The 'wear out too fast' concept is wildly overblown. You can listen to old rumors, or read actual test data.
600TB total writes - http://techreport.com/review/2...
800TB total writes, and some of these consumer grade drives start to fail - http://techreport.com/review/2...
"By far the most telling takeaway thus far is the fact that all the drives have endured 600TB of writes without dying. That's an awful lot of data—well over 300GB per day for five years—and far more than typical PC users are ever likely to write to their drives. Even the most demanding power users would have a hard time pushing the endurance limits of these SSDs."
By contrast, my main home machine (120GB Kingston SSD) has ~7GB total, in over 2 years of 24/7 use. I'll leave you to do the math on lifespan for that.
The actual wear leveling algorithms are proprietary, but rest assured that they do not use flash as temporary memory, and neither do they read an erase block, change one sector and write the erase block back. One thing flash controllers do is maintain a list of unused sectors. So, if you write to one sector, the data goes into an empty sector of a different erase block and the controller remembers that the sector's old location is now unused (and where the sector is now). That's where the TRIM command helps: It marks sectors as unused without using up a different sector somewhere else. When the drive needs more free erase blocks, it copies the remaining data from mostly "abandoned" erase blocks and flashes (erases) the old erase block. All that and more brings down the write amplification, which measures the average number of sectors actually written for each write to a sector. Intel claims a write amplification of just 1.1 for one of its controllers. Also, wear leveling makes sure that erase blocks are used evenly. Otherwise writing the same few sectors over and over again would burn out the drive in seconds. All in all you can expect to write at least a few hundred times the capacity of the drive, in any order and to any sectors you want, before you need to worry about flash cell wear.
Any wear levelling worth its salt will not do what the grandparent wrote.
Yes, which is where the smarter controllers come in, and where you have the process of "garbage collection". There was a piece a while ago on TRIM not being support on some Apple gear, if I'm not mistaken.
I'm not a complete idiot... Some parts are missing.
RAID in acronym only. The R means redundant, and RAID 0 is not redundant.
Contribute to civilization: ari.aynrand.org/donate
The "big win" for solid-state for a lot of applications is shock-resistance.
Most server racks, desktops, and set-top-boxes outside of earthquake zones don't have this requirements but anything mobile does.
Having said that, my ideal laptop would have oodles of storage but the drive would hardly ever need to "spin up" because almost everything I need would fit in the SSD. In "real terms" this would be at least a 128GB SSD plus at least 2TB of less expensive storage.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
No, it doesn't. It doesn't protect you against losing data in a fire, it doesn't protect you against losing data to malware, and it doesn't protect you against losing data to making a mistake. All changes are automatically propagated across all disks. Backup protects you against losing data.
What RAID 15 does is protects you against losing a day of work because one disk failed - that is, it protects against loss of uptime.
Most manufactures leave any number of gigabytes of flash unmappable for filesystems, that way you can never fill up the drive, even if you fill up the file system. Most pro/enterprise versions of the drive just leave a larger area unmapped.
With 3 bits per cell, how long before the data fades?
This is the reliability issue that nobody wants to talk about. I am sure that many others are like myself, with a closet full of old PCs. I like the idea that if I were to pull one out and power it on after having sat unplugged for a span of years, it would still boot (CMOS battery BIOS issues not withstanding) and would still have all of the data I left it with.
SSDs on the other hand won't even guarantee that your data will still be there after *only one year* of being powered off, and as we've dipped below the 34nm process, sometimes SSDs are warranted for even less.
http://cylan.deviantart.com/gallery/
More accurately, recent versions of OSX have their use of TRIM commands limited to the 'apple endorsed' models of SSD, the ones the machine ships with. There's some dispute over the reasons for this. One faction claims it's Apple trying to sabotage upgrades, making it so that if you buy an after-market SSD rather than paying their insane markup performance will become awful. Another faction claims it isn't deliberate sabotage, but rather a lack of interest in testing for unsupported hardware configurations: TRIM can potentially malfunction horrible if the SSD doesn't impliment it in quite the expected way, and Apple has only coded and tested it for their preferred models. By disabling it on third-party hardware they remove the need to test for fifty-odd different devices to make sure it isn't going to corrupt data.
Risky Array of Imminent Disaster.
Depends on the application. For a workstation or build box, we configure swap on the SSD.
The point is not that the build box needs to swap, not with 32G or more ram, but that having swap in the mix allows you to make full use of your cpu resources because you can scale the build up to the point where the 'peaks' of the build tend to eat just a tad more ram resources than you have ram for (and thus page), which is fine because the rest of the build winds up being able to better-utilize the ram and cpu that is there. So putting swap on a SSD actually works out quite nicely on a build box.
Similarly, for a workstation, the machine simply does not page enough that one has to worry about paging wearing out the SSD. You put swap on your SSD for another reason entirely... to allow the machine to hold onto huge amounts of data in virtual memory from open applications, and to allow the machine to get rid of idle memory (page it out) to make more memory available for active operations, without you as the user of the workstation noticing when it actually pages something in or out.
A good example of this is when doing mass photo-editing on hundreds of gigabytes of data. If the bulk storage is not a SSD, or perhaps if it is accessed over a network that can cause problems. But if the program caches pictures ahead and behind and 'sees' a large amount of memory is available, having swap on the SSD can improve performance and latency massively.
And, of course, being able to cache HDD or networked data on your SSD is just as important, so it depends how the cache mechanism works in the OS.
So generally speaking, there are actually not very many situations where you WOULDN'T want to put your swap on the SSD. On machines with large ram configurations, the name of the game is to make the most of the resources you have and not so much to overload the machine to the point where it is paging heavily 24x7. On machines with less ram, the name of the game is to reduce latency for the workload, which means allowing the OS to page so available ram can self-tune to the workload.
-Matt
My first computer stored data on audio tape! I don't know what their capacity was, but I remember my father borrowing games from work to run through a dual-cassette deck. Some of them were copies of copies, and you had to fiddle with the treble knob to get them to read.
I don't think we're beating that unless someone here is old enough to have used core memory or fluid delay lines.
6TB for $300 is $50 per terabyte, while current pricing is around $400 per terabyte. That's a factor of 8, not 16. I based my math on 18 month doubling, but that's for performance rather than density, so I was admittedly off. Still, that should take you to roughly 3 * 24 = 6 years, not far off my original figures.
In terms of the applicability of Moore's Law to SSD pricing, prices for SSDs have been dropping far faster than Moore's law since the first practical SSDs hit the market. My first consumer SSD was purchased in 2009 at $8750 per TB. Prices today are at about $400 per TB. That's a factor of 22 price drop in roughly five years.
Yes and no - they simply don't QA every drive that ever existed or will exist, because they didn't ship them and it would be ridiculous to do that anyway. Where the change was, is that they implemented code signing on kernel extensions in order to beef up security a bit, and the side effect is that the ugly binary patch people were applying to the AHCI kext is quite broken. If anyone out there was patching any of the other 200+ kexts that ship with OS X, they have a similar problem; unless they turn off kext signing. Which you are free to do with a simple nvram flag.
Or, it's postulated that you could create your own signing cert, import it into system.keychain, and then re-sign the patched kext; but I'm not aware of anyone doing that. The third option is for some nice SSD manufacturer to make a proper signed driver, but they don't want to spend the time or resources.
Either way, it's a tempest in a teapot. Software vendor is blamed when unsupported hack applied without their knowledge is broken in a major upgrade. In other news, fire is still hot.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
They use capacitors to ensure they have enough time to write out the RAM after power down.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Sadly the ram air intake at the front of the structure does little for aerodynamics. There is too much damping material (soup meat) in the chamber to pass through cleanly to the exhaust port. Additionally, the locomotive openings are often shaped in such a way to create lift at higher velocities, thus reducing overall stability.
I don't know what their capacity was...
Well a C90 tape had a 90 minute length and, depending on you computer the data was written at 1200 baud (BBC Model B) to ~1500 baud for a ZX spectrum. Unfortunately there was some overhead so lets say this was 20% (guesstimate). This would give a tape capacity of 90x60x(1200/8)x0.8=648000 bytes or ~633 kB. Some people used to use C120s which would get you an extra 33% but those tapes were thinner and more likely to break or suffer degradation in sound quality which meant you lost your program. With a Spectrum and a C120 you'd might be pushing the dizzying heights of a whole MB on tape.
You might as well ask the same question about a hard drive. If you power down a hard drive and put it on a shelf for a year, there is a better than even change that it will be dead when you try to power it up again, and an even higher chance that it will die within a few days.
A powered-down SSD that has been written once should be able to retain data for ~10 years or so. Longer if kept in a cool place. As wear builds up, the retention time drops. You can look up the flash chip specs to get a more precise answer. A powered-up SSD should be able to retain data almost indefinitely as the self check will relocate failing sectors as they lose charge. However, in practical terms, it also depends on how the drive firmware is stored. The drive will die when the firmware is no longer readable. But that is true for hard drives as well.
-Matt
Hard Drive [newegg.com]: $429
Whole Computer [newegg.com]: $400 or less.
Ah, yes. Confucius say, the path to mastering pedanticism is paved with low UIDs.
Thunderbolt is external PCIe, and is thus nice for overpriced laptops and trash can shaped workstations. Else it is a lot cheaper to use your internal PCIe. PCIe 2.0 4x will do the same job as Thunderbolt 2.0 - and so you can either use a PCIe 2.0 4x card for your SSD (or a 3.0 one to yet double the bandwith, seems the 3.2TB Samsung SSD uses that) or for a 10Gb NIC.
Real issue with 10Gb ethernet is the cost and then the power use, not anywhere near a graphics card but around the 10W mark which is significant. A high end motherboard was just announced (2011-3 socket) which has a dual 10Gb NIC built-in, which uses 14 watts.
If you actually use a kindle, you will realize that the 4 week claim is quite true. I do not know the fine print etc but I have been using one for several years and it still gives me a nice 3-4 weeks battery. I read about 2-3 hours daily.
Wealth is the gift that keeps on giving.