Even with only six subjects, the fact that we didn't experience any failures until after 700TB is a testament to the endurance of modern SSDs. So is the fact that three of our subjects have now written over a petabyte. That's an astounding total for consumer-grade drives, and the Corsair Neutron GTX, Samsung 840 Pro, and compressible Kingston HyperX 3K are still going!
The selection of brand comes from more large-scale trends in failure, like what OCZ went through with some of their Vertex drives. They were firmware bugs rather than degredation of NAND that led to a more sudden bricking of the drive and loss of data.
A properly functioning drive will last ages now. Not all manufacturers produce the same rate of improperly functioning drives, so that's where the discrepency in product exists.
I've been reading TR since they split off from Ars, and never had to register to view content. I think that perhaps something may be amiss with your browser.
Given our limited sample size, I wouldn't read too much into exactly how many writes each drive handled. The more important takeaway is that all of the SSDs, including the 840 Series, performed flawlessly through hundreds of terabytes. A typical consumer won't write anything close to that much data over the useful life of a drive.
That's exactly the issue - you can't have a takeaway if you don't have a reasonable sample size. Are these drives all in the top 5% of quality for their respective brands? We'll never know unless we do a larger study.
The odds of all six drives being in the top 5% by chance is one in 64 million. So I think we can at least rule out that extreme with decent confidence.
I find it astonishing that none of the drives that died finished in a state where their data was accessible. Some of these drives even intentionally self-brick themselves at end-of-life:
According to Intel, this end-of-life behavior generally
matches what's supposed to happen. The write errors
suggest the 335 Series had entered read-only mode. When
the power is cycled in this state, a sort of self-destruct
mechanism is triggered, rendering the drive unresponsive.
So you enter a read-only mode, and then on power cycle you self-destruct, making the intact data inaccessible? In what circumstance is that possibly the right choice?
Intel says attempting writes in the read-only state could
cause problems, so the fact that Anvil kept trying to push
data onto the drive may have been a factor.
Oh, I see. Maybe it's to prevent the unwanted writes from damaging the drive. Wait, what? The attempted writes can damage a drive that is in read-only mode?
Yeah, by all means they can block further writes to the drive, but you should always be able to read from it, even if the drive can't guarantee that the data is correct.
I've recovered many hard disks that have gone bad in various ways, including multiple Seagate Barracuda 7200.11 drives that suffered from the BSY bug, and I've never had a disk that I couldn't recover at least some of the data from, even if that meant hooking up serial cables and re-reading the data multiple times (eg: Spinrite).
But a drive that disappears completely when things go bad is never a good outcome.
Good point. Ok, but does Intel provide a published specification of how to send some sort of custom command to resurrect the drive in read-only mode, you know, so I can take it to a friendly geek and get my data back?
That is a good point, as long as it can only be done after it self-bricks and it only restores to read-only then I cannot see a problem with regards to my earlier point since any consumer is going to notice pretty damn quick that they cannot write to the drive.
This behavior doesn't stop you from selling an almost dead SSD. And if you sell a dead one it will be obvious that it can't be written to; that's not going to be a very convincing scam.
Sorry, clarification: "almost-dead" in this case means "on the verge of the intel software self-bricking itself" rather than the drive itself being buggered.
Based on what I read from the article it implies that at this point the drive itself MAY be ok but not reliable so the intel software pro-actively commits suicide.
Without the self-bricking you could sell a drive that has reached this point to some unsuspecting person since it ostensibly works but is unreliable, if it fails 2 months later then the seller can just deny responsibility.
Although why it 100% self-bricks instead of going into "read-only brick" mode is a good question.
My guess is that Intel couldn't coerce the SandForce controller into behaving nicely. Of course if anyone asks them about the behavior, it's a feature, not a bug. But really, selling almost-dead SSDs is not a big problem. These endurance tests show that you'd have to overwrite a 240GB SSD every day for 5 years before getting close to exhausting it. Drives will become obsolete before they wear out.
Last I checked, Intel used their own controllers in their enterprise SSDs. Now I wonder if their older consumer drives like the X25-M (which used in-house controllers) become read-only instead of bricking themselves.
Is the consumer market for second-hand drives large for them to be concerned about it? I always thought that >99% of people keep the drive their desktop/laptop came with and junk/sell/donate the whole thing without ever turning a screw. The number of people who are savvy enough to know about SSD, be willing to upgrade a drive, willing to shop for a used one vs a new one from Dell/Amazon/Newegg, and still be able to be duped might be a pretty small market.
Not to mention the number of drives bricked by overuse in the hands of unscrupulous sellers willing to put in the effort to earn a (rather pitiful) sum on the second-hand market for an outdated driver is probably... zero. Or vanishingly small, in any case.
> Intel really doesn't want its client SSDs to be used after the flash has exceeded its lifetime spec. The firm's enterprise drives are designed to remain in logical disable mode after the MWI bottoms out, regardless of whether the power is cycled. Those server-focused SSDs will still brick themselves if data integrity can't be verified, though.
> So you enter a read-only mode, and then on power cycle you self-destruct, making the intact data inaccessible? In what circumstance is that possibly the right choice?
I agree with you - I was surprised by the behaviour the article describes. That said, the obvious alternative of entering a permanent read only state is still problematic: how do you dispose of such a drive safely when you can't overwrite the data that remains? You'd need people to be aware of the secure erase command and continue to support that in read only mode.
Filesystem needs to shutdown and sync correctly. I think best way is to make writes slower and slower. FS can still close, and admin will notice something is wrong.
That's a good idea, although it feels kind of dirty to intentionally degrade performance when S.M.A.R.T. can allegedly provide ample warning.
I say "allegedly" because implementation of S.M.A.R.T. attributes is so inconsistent between drives/vendors, and is often totally undocumented. Most manufacturers seem to provide a Windows program that monitors the attributes, but since they're usually undocumented you're kind of out of luck if you're on another OS...
That's just as much of a problem with Intel's current solution though - the data's still present and can probably be retrieved with the correct tools, it's just inaccessable to the user. What's more, the brick mode almost certainly blocks access to the secure erase commands needed to safely dispose of the drive along with every other command, whereas a better end-of-life mode could allow secure erase.
You cannot erase data from SSD and know it is erased. The last time I researched the subject the official DoD policy for secure SSD erasing was - grind them to dust. And I happen to agree with them.
There's nothing keeping a properly implemented secure erase from working -- all the data on disk should be written out encrypted so secure erase is just cycling the key. It has the advantage of being much faster and something you can do in software (and repeatedly)
Of course, for retiring a drive there's no good reason not to just physically destroy it.
Agreed. It's discussed in the comments of the article as well. Some quotes:
> For a drive that voluntarily went into read only mode, I didn't expect it to get bricked, especially for a consumer drive. I am disappointed with Intel's engineers.
> I'd like to be able to read my data, even most of my data, if my SSD has failed. Disabling writes seems quite fair, disabling reads seems unnecessary and potentially cruel, depending on what data has been laid down since the last backup.
> ...I think it's a big deal, I'd want my SSD drive to tell me when it's time to move my data safely to another drive, right?
> Not only Intel but all three. Read only, even with some corrupt data, is far far better than becoming inaccessible. The three failed miserably, SMART warnings and writing-much-over-spec notwithstanding.
> ...I find it concerning since the SSDs appear to brick themselves instead of going into read only mode, once they have reached their write limits.
This site is so cute. Half the time it's the Ed Snowden show, all about how to use PGP to thwart the NSA. Half of the time it's complaining about privacy protections in SSDs.
Think about it. If the SSD fails to erase, do you want that to mean it's readable forever? Would you be happy if the NSA was snooping around and your SSD refused to do anything other than disgorge secrets? This feature is good privacyware. If the drive can't be erased it also can't be read.
I am sure the three-letter agencies have electrical engineers who can swap out or reflash the controller chips on the SSDs, and recover most of the data.
Maybe. Am I involved in a lawsuit with my wife or my boss or my ex-partner? Perhaps a lucrative divorce option?
If so, I think she/he can afford to spare a few thousand dollars to some recovery service to read my drive.
But you started talking about this being a "privacy" feature, and now that they told you it's not really protective, you go on about how it's good enough for one's "wife". As if that's where privacy concerns end...
The FBI is known to pick apart spinning disk drives and retrieve data directly from the platter using a scanning tunneling electron microscope. What makes you think the NSA doesn't know how to do the same and perhaps with SSDs?
Which is better: my SSD fails, taking all unbacked up data with it, or my SSD fails and I can rescue my data and dispose of the drive carefully?
You seem to live in a bizarre fantasy world where if a drive dies, people just go out onto the street and hand it to random strangers, saying 'please! try to take my data and invade my privacy!' No, what happens when a drive dies is that it gets chucked and hit with a hammer if it had (unencrypted) data on it.
I don't know about the consumer-grade OSs you mentioned, but I have booted Ubuntu from read-only media countless times - it's a good way to start compute nodes that'll get and save their data to a network.
In light of recent revelations of manufacturers giving reviewers different hardware than what they sell to the public, I think it's important to find out where these drives came from. If techreport just walked into a bestbuy (or amazon) and bought the six drives consumer-reports-style then I'd be willing to believe that this is a legitimate test of consumer hardware, but if they were given the drives from the OEMs the there is a chance that some jiggering was done to boost scores.
Though I guess in the long run if they do even half as well as the report suggests we're probably in good shape.
According to this older article Intel SSD were the only ones that reliably stored data in a write-sync-powerloss scenario:
http://lkcl.net/reports/ssd_analysis.html
But if they also completely brick themselves at EOL then it doesn't like a good choice, so ... are there any reliable SSDs??
For most rational definitions of reliable, absolutely. In this case inexpensive MLC or even TLC drives withstood hundreds of TB or more of writes before failing, clearly indicating their remaining lifespan the entire time. In the common applications of these drives, they're unlikely to ever see tens of TB of writes.
They can't last forever. It is odd that the Intel "bricks" itself, and that sounds more like a fault than anything (I'm at a loss to explain how that makes sense as a behavior, beyond maybe "hiding your data after you've lost the ability to wipe it"), but again it was clearly communicating the entire time that its death was imminent.
As an aside, that power test you linked was an extreme test of thousands upon thousands of abrupt power cuts while a write-back cache was enabled and populated, against a very small number of drives. It is not relevant to consumer products (where few or no drives have power retention), but it's even odder in the enterprise space, where power assurance is at the rack or even center scale, not component by component.
Good point about "communicating the entire time that its death was imminent".
Regarding the power tests I think the relevance is that the drives lie to the OS about sync, and just claim they completed it when its in their cache, and then hope they can write it to flash before power loss / before the capacitor runs out. The cache wouldn't be a problem if it could be reliably flushed.
As it is they will corrupt the integrity of anything that relies on syncs / write barriers like databases.
I can't give you any useful information, aside from saying that I tried to work out the answers to these questions myself not long ago and the result was 'it depends'. Many of the values are manufacturer specific.
Most of the values count down from 100, so eg you power cycled this enough to reduce the count form 100 to 99, but it is ok until it reaches the threshold value of 0. So your drive is pretty new in terms of usage.
You should run the short and long smartctl tests occasionally to get more reliable results though (smartctl -t short and smartctl -t long)
Check 177, 235 and 241. When the normalized value gets close to 0 (for any of them) start to worry.
The ones I listed are the main wear indicators, for the others I'd worry if they had any value at all in the RAW column, even if the normalized value was not close to 0. If that happens then carefully research the implications of whichever one it happened to.
If this is a linux server then if you configure smartmontools correctly it will email you when it gets close.
I just tried to find out about 235 (POR recovery count), and from what I gather this counts any hard power cycles you've "inflicted" on your machine, is that right?
I suspect that between 177 (wear level) and 241 (blocks written), 177 may be the best indicator, because 241 may not take into account write-amplification - useful discussion of this from Anandtech: http://www.anandtech.com/show/6459/samsung-ssd-840-testing-t...
First: I jumped into the comments before reading the article.
I have quite some experience with Flash in the form of eMMC and SD/CF. SSDs aren't that much different from those on the low level.
The controller that comes with the flash storage contains a core that manages the bad blocks. Comparable to bad sector management on HD. The software these controllers run contain a lot of rules of thumb to manage bad blocks, which is where these full failures come from IMO.
Each controller has access to a pool of reserve blocks that are used when bad blocks are detected. Once those run out the embedded software starts showing weird behavior when using the device and shortly after there's a complete fail.
I think the pool of reserve blocks is "Used_Rsvd_Blk_Cnt_Tot" in your list. Apparently there are 100, of which you consumed 0. There's a threshold at 10 so I assume that's where the diagnostics software will warn you.
> The 100 is a normalized number, it's not the actual number of blocks.
I'm not too sure about that. The only ref I can give is that they use the suffix "Cnt_Tot" which means "total count". When it's a percentage they denote it as such as in "Perc_Rated_Life_Used" and "Workld_Host_Reads_Perc". Don't be surprised by the low count (100).
That's how SMART attributes work. 100 means AOK and 0 means failed. The normalized number is reported by the drive, calculated by a formula based off the raw values and MTBF data determined by the manufacturer.
ID # 179 Used Reserved Block Count (total)
This attribute represents the number of reserved blocks that have been used as a result of a read, program or erase failure. This value is related to attribute 5 (Reallocated Sector Count) and will vary based on SSD density.
.. so at least for samsung there's use of exact numbers.
The ones with the "P" flags are prefail indicators that the controller manufacturer thinks will indicate failure. When value goes below threshold, it sets a SMART prefail status indicator that the host controller can poll. Unfortunately for SATA there is no way for SSD to interrupt the host controller to give such a warning so you need some kind of monitoring software to periodically poll the SMART status.
Your drive looks in good shape in my opinion but thinks can always change suddenly so always backup.
Samsung, largely due to reputation. Samsung have been fairly consistent in turning out decent, reliable SSDs while Corsair have historically been all over the map.
I probably wouldn't take this comparison into account for buying decisions: they only tested one specimen of each. For me, what's mostly interesting about this is _how_ the drives died (not all that gracefully).
this is the trouble with ssds, they just die. but they're fast before they do. but it's ok because everyone has backups right? i know i do, and raid1 just incase.
on a side note, glad i paid the extra cost for the 840 pro!
in my experience hdds have signs they're going to die soon, they go slow, click a lot, get smart errors, things get corrupt etc. where as with flash media it all seems fine, but suddenly isn't.
not that this is a rule, i've seen hdds fail instantly for no reason as well, and flash media throw a massive wobbler but still be recoverable. but in my experience this is not the normal behaviour.
but who cares as long as you have backups and a contingency plan?
The critical difference is the SSDs all indicated they were "past expiration date" with the SMART wear indicators. The Samsung indicators were overly conservative it appears, dropping to dead long before the drive actually died. Their software is garbage though, reporting a healthy drive even though the SMART indicators are telling you it is close to death. Obviously they never bothered to test a nearly-expired drive... probably the same reason the Intel drive bricked itself instead of coming up in read-only mode. I doubt they tested this scenario very well (not that we software engineers ever just test the golden path either...)
In any case, all the drives so far indicated they were destined to keel over via the SMART attributes long before it actually happened... Certainly long enough to buy a new drive and copy all the data, even for the less reliable TLC drive.
In fact even under a heavy workstation load you'd have enough time to save up money working a minimum wage part-time job, order the SSD when it goes on sale, wait for it to arrive via ground shipping, forget that you need an external SATA adapter, save up for that, order it, wait for shipping, then copy the data.
My original Intel X25-M G2, which I used for several years in my daily workstation, had around 4 TB total writes before I replaced it. That's two orders of magnitude lower than the apparent limit for these drives.
> In fact even under a heavy workstation load you'd have enough time to save up money working a minimum wage part-time job, order the SSD when it goes on sale, wait for it to arrive via ground shipping, forget that you need an external SATA adapter, save up for that, order it, wait for shipping, then copy the data.
That's a really interesting metric. Can we call that the xenadu factor?
In my environment SSD are either in RAID sets or mirrored like any traditional drive. This is just common practice, so a drive bricking itself while odd would not endanger the data.
Our systems vendor is making a big push for SSD only systems for many reasons. Namely speed but the reduced costs for electricity and cooling are apparently significant too. There there is the form factor, they are going to be much more space efficient than spinning drives
It'd be interesting to see a real world test of this. I'm not sure how large the sample variation is with these units, but if you're actually hitting the write limits of your disks I don't think mirroring is going to be the most effective solution - as both disks are likely to start failing at roughly the same sort of time.
Mirroring is really useful with spinning rust, where failures are (more or less) unpredictable and you need a spare to use while the first is replaced. I wonder if there's a better solution when the failure of the drive is more predictable that avoids having a second unit sitting there all the time - especially for applications where the data isn't absolutely critical.
in the same train of thought does not compute. Raid arrays do not protect your data. Only backups will do that.
In fact, striped raid arrays will tend to lose data faster than a drive by itself - when it comes time to calculate parity, they'll find an overlooked mistake and take out 2-3 more drives, writing off all the data on that cluster at once.
The "R" in RAID is for "redundant". Unless we are talking about RAID-0, which should not even be called "RAID" (AID, perhaps?), it does, indeed, protect you from individual drive failure (how many and which drives can fail depends on the RAID configuration) and, therefore, the whole array will be, on average, more reliable than the least reliable of its component drives.
There is, however, a lesson I learned - never, ever build an array with drives of the same maker, model and batch, as they will have a tendency to fail at the same time for the same reasons. I did not build the array (I'd never do it), but it failed under my watch. Luckily, the first drive to go went one week before the second and the third and I had a plan-B.
I wonder if there's a way to get those ssd metrics like wear indication and reallocated sectors on the macbook? Not that I'm ever likely to write that much data
I'd like to see the same kind of test with identical drives mirrored (RAID 1 or another suitable way to precisely duplicate disk I/O). One of the things I've always wondered is if two SSDs from the same lot are more likely to fail at the same time. It's not unusual to have such an arrangement in a newly deployed server. Longevity is (more than) nice, but simultaneous failure is still a disaster, whenever it happens. Does it make sense to provision drives that don't match exactly (in age, manufacturer, etc.) in order to avoid potential issues?
Out of curiosity, how heavily do you tax your consumer SSDs? I have a Samsung 840 in my desktop for the system and applications (while keeping media and big files on a platter) and after approximately one year I am at 1.5TB of data written. That seems to give me another 200 years before the wear indicator reaches 0.
Those numbers seem very strange to me. My main system is an oldish laptop running Linux, and its primary partition is a 200 GB ext4 one, which was originally created over 5 years ago. Its lifetime writes (tune2fs -l) shows 2.4 TB, which includes /home. How would you manage 1.5 TB written for just system and apps over 1 year?
I'm an overly cautious person when it comes to data so I'm still holding off - these results look promising enough to throw some of that caution to the wind.
I've had a 512GB OCZ Vertex 4 for almost 2 years. Depending on the OS used, you should be able to automatically put more valuable fast-changing user specific data on a HDD, while keeping your system and apps on a SSD. I did that for Windows 7, and everything has been great.
I'd be interested to know the best way to set that up. My next Windows PC will have an SSD for the system drive and a regular harddrive for other storage. I figure I can use junction points to map certain folders to the HD but I'm not sure what would be a good configuration.
If you use Windows 8, I've heard that doing something like this causes massive problems when updating Windows itself. It's been fine for Windows 7 though.
Correct. I did this exact thing (used a junction point for my User directory) and could not upgrade from 8 to 8.1. Moved it back to "normal" and it went fine. This is a known "issue", so don't do junction points, just do the traditional "Move This Folder" for each special folder (Documents, Downloads, etc.)
I did that with my first SSD system, mapped C:/Users to an separate HDD. Honestly it was more trouble than it was worth.
Using a junction point for a critical folder like that requires booting into a recovery mode and entering a bunch of incantations into a cmd window. And things will go sideways if you have to remove the Users drive at any point.
An easier course of action is to just use the Libraries functionality under windows and map each of those to write by default into your HDD. so most of my documents reside in D:\media\Documents instead of C:\Users\[blah]\Documents. Then you can also leverage the SSD speed for stuff in your AppData.
If you're going to spend the extra money for an SSD, your valuable fast-changing data is exactly what you should put on the SSD. Buying an SSD and then not taking advantage of it is totally irrational.
I've never heard of an HDD that presented a reliable, linear prediction of their own death years in advance, which is how these SSDs behave. HDDs usually fail suddenly and completely, following the well-known bathtub curve lifetime distribution. There was a paper from one of the big cloud shops about how SMART lacks predictive value for HDD failure.
Compared to HDD, SSD failure modes are highly desirable and easy to handle.
I wonder what this means for shops like digital ocean and now Linode that sell SSD backed VM's. Those things must be constantly writing. Even in a RAID array, the load is even and the drives should fail at the same time, kinda making RAID a little useless. I'm guessing they mix and match different vendors and models.
'Verify disk' in Disk Utility from time to time. I usually get error messages and have to boot from the recovery partition to repair my system disk (Command-R).
According to the local Genius Bar, that's normal to a certain degree. For one MacBook Pro, I got the mainboard and the SSD repaired on warranty.
I am wondering if these issues are related to HFS+ or to the reduced reliability of SSDs …
I have experienced this on several spinning rust-based Macs (with multiple drives that pass SMART and several other types of tests) over the past decade as well as occasionally on SSDs. It's HFS+ or some sort of other OSX issue.
111 comments
[ 2.8 ms ] story [ 191 ms ] threadEdit: My apologies, mixed up this with other youtube wsj article which is behind paywall. Consequence of opening multiple articles at once.
Even with only six subjects, the fact that we didn't experience any failures until after 700TB is a testament to the endurance of modern SSDs. So is the fact that three of our subjects have now written over a petabyte. That's an astounding total for consumer-grade drives, and the Corsair Neutron GTX, Samsung 840 Pro, and compressible Kingston HyperX 3K are still going!
A properly functioning drive will last ages now. Not all manufacturers produce the same rate of improperly functioning drives, so that's where the discrepency in product exists.
That's exactly the issue - you can't have a takeaway if you don't have a reasonable sample size. Are these drives all in the top 5% of quality for their respective brands? We'll never know unless we do a larger study.
I've recovered many hard disks that have gone bad in various ways, including multiple Seagate Barracuda 7200.11 drives that suffered from the BSY bug, and I've never had a disk that I couldn't recover at least some of the data from, even if that meant hooking up serial cables and re-reading the data multiple times (eg: Spinrite).
But a drive that disappears completely when things go bad is never a good outcome.
You will notice that their Enterprise SSDs do not self-brick.
[EDIT] Read down for clarification regarding "almost-dead"
Based on what I read from the article it implies that at this point the drive itself MAY be ok but not reliable so the intel software pro-actively commits suicide.
Without the self-bricking you could sell a drive that has reached this point to some unsuspecting person since it ostensibly works but is unreliable, if it fails 2 months later then the seller can just deny responsibility.
Although why it 100% self-bricks instead of going into "read-only brick" mode is a good question.
Last I checked, Intel used their own controllers in their enterprise SSDs. Now I wonder if their older consumer drives like the X25-M (which used in-house controllers) become read-only instead of bricking themselves.
http://www.xtremesystems.org/forums/showthread.php?271063-SS...
X25-M G1 dies at ~883TB written (without TRIM, so in reality much more), also by just failing to be detected.
On the first page of that thread you see an X25-V (40GB) with 1.5PB written and apparently it is still alive as of earlier this year...
http://www.xtremesystems.org/forums/showthread.php?271063-SS...
Or, in some OLTP scenarios, every few minutes for a month or so.
How do you know? Was there a test that managed to put one of the enterprise drives into Read only mode? Nope.
This brisking of intel wasnt intentional, it sounds like a broken firmware.
> Intel really doesn't want its client SSDs to be used after the flash has exceeded its lifetime spec. The firm's enterprise drives are designed to remain in logical disable mode after the MWI bottoms out, regardless of whether the power is cycled. Those server-focused SSDs will still brick themselves if data integrity can't be verified, though.
I agree with you - I was surprised by the behaviour the article describes. That said, the obvious alternative of entering a permanent read only state is still problematic: how do you dispose of such a drive safely when you can't overwrite the data that remains? You'd need people to be aware of the secure erase command and continue to support that in read only mode.
I say "allegedly" because implementation of S.M.A.R.T. attributes is so inconsistent between drives/vendors, and is often totally undocumented. Most manufacturers seem to provide a Windows program that monitors the attributes, but since they're usually undocumented you're kind of out of luck if you're on another OS...
Of course, for retiring a drive there's no good reason not to just physically destroy it.
You should do it with some care so to keep the various materials easily recyclable.
> For a drive that voluntarily went into read only mode, I didn't expect it to get bricked, especially for a consumer drive. I am disappointed with Intel's engineers.
> I'd like to be able to read my data, even most of my data, if my SSD has failed. Disabling writes seems quite fair, disabling reads seems unnecessary and potentially cruel, depending on what data has been laid down since the last backup.
> ...I think it's a big deal, I'd want my SSD drive to tell me when it's time to move my data safely to another drive, right?
> Not only Intel but all three. Read only, even with some corrupt data, is far far better than becoming inaccessible. The three failed miserably, SMART warnings and writing-much-over-spec notwithstanding.
> ...I find it concerning since the SSDs appear to brick themselves instead of going into read only mode, once they have reached their write limits.
Think about it. If the SSD fails to erase, do you want that to mean it's readable forever? Would you be happy if the NSA was snooping around and your SSD refused to do anything other than disgorge secrets? This feature is good privacyware. If the drive can't be erased it also can't be read.
If so, I think she/he can afford to spare a few thousand dollars to some recovery service to read my drive.
But you started talking about this being a "privacy" feature, and now that they told you it's not really protective, you go on about how it's good enough for one's "wife". As if that's where privacy concerns end...
You seem to live in a bizarre fantasy world where if a drive dies, people just go out onto the street and hand it to random strangers, saying 'please! try to take my data and invade my privacy!' No, what happens when a drive dies is that it gets chucked and hit with a hammer if it had (unencrypted) data on it.
Seriously, it's the 21st centuary and everyone should always be making backups.
Though I guess in the long run if they do even half as well as the report suggests we're probably in good shape.
and http://www.tomshardware.com/reviews/ssd-reliability-failure-...
Together with this one should give a good picture on SSDs
But if they also completely brick themselves at EOL then it doesn't like a good choice, so ... are there any reliable SSDs??
For most rational definitions of reliable, absolutely. In this case inexpensive MLC or even TLC drives withstood hundreds of TB or more of writes before failing, clearly indicating their remaining lifespan the entire time. In the common applications of these drives, they're unlikely to ever see tens of TB of writes.
They can't last forever. It is odd that the Intel "bricks" itself, and that sounds more like a fault than anything (I'm at a loss to explain how that makes sense as a behavior, beyond maybe "hiding your data after you've lost the ability to wipe it"), but again it was clearly communicating the entire time that its death was imminent.
As an aside, that power test you linked was an extreme test of thousands upon thousands of abrupt power cuts while a write-back cache was enabled and populated, against a very small number of drives. It is not relevant to consumer products (where few or no drives have power retention), but it's even odder in the enterprise space, where power assurance is at the rack or even center scale, not component by component.
Regarding the power tests I think the relevance is that the drives lie to the OS about sync, and just claim they completed it when its in their cache, and then hope they can write it to flash before power loss / before the capacitor runs out. The cache wouldn't be a problem if it could be reliably flushed. As it is they will corrupt the integrity of anything that relies on syncs / write barriers like databases.
These are the values for a Samsung 830 SSD:
Monitor all? Or just the wearlevel-count? Or watch only for the program or runtime error counts? What do these even mean?You should run the short and long smartctl tests occasionally to get more reliable results though (smartctl -t short and smartctl -t long)
The ones I listed are the main wear indicators, for the others I'd worry if they had any value at all in the RAW column, even if the normalized value was not close to 0. If that happens then carefully research the implications of whichever one it happened to.
If this is a linux server then if you configure smartmontools correctly it will email you when it gets close.
I suspect that between 177 (wear level) and 241 (blocks written), 177 may be the best indicator, because 241 may not take into account write-amplification - useful discussion of this from Anandtech: http://www.anandtech.com/show/6459/samsung-ssd-840-testing-t...
I have quite some experience with Flash in the form of eMMC and SD/CF. SSDs aren't that much different from those on the low level.
The controller that comes with the flash storage contains a core that manages the bad blocks. Comparable to bad sector management on HD. The software these controllers run contain a lot of rules of thumb to manage bad blocks, which is where these full failures come from IMO.
Each controller has access to a pool of reserve blocks that are used when bad blocks are detected. Once those run out the embedded software starts showing weird behavior when using the device and shortly after there's a complete fail.
I think the pool of reserve blocks is "Used_Rsvd_Blk_Cnt_Tot" in your list. Apparently there are 100, of which you consumed 0. There's a threshold at 10 so I assume that's where the diagnostics software will warn you.
The 100 is a normalized number, it's not the actual number of blocks. (A percentage basically, so 100% are still left.)
If the drive used any blocks at all I'd worry about it, I would not consider it a wear indicator but rather a failure indicator.
I'm not too sure about that. The only ref I can give is that they use the suffix "Cnt_Tot" which means "total count". When it's a percentage they denote it as such as in "Perc_Rated_Life_Used" and "Workld_Host_Reads_Perc". Don't be surprised by the low count (100).
In Smartmontools I found the code for this variable:
http://smartmontools.sourceforge.net/doxygen/atacmds_8cpp_so...
It's code 179 (0xB3).
From Samsung's website:
http://www.samsung.com/global/business/semiconductor/minisit...
.. so at least for samsung there's use of exact numbers.From Intel's website:
http://download.intel.com/newsroom/kits/ssd/pdfs/intel_ssd_5...
(Ctrl-F for "Available Reserved Space")
.. they use a normalized value (100).
So it can be either percentage or absolute value, depending on manufacturer.
Your drive looks in good shape in my opinion but thinks can always change suddenly so always backup.
on a side note, glad i paid the extra cost for the 840 pro!
As opposed to hard drives, which are always so good about failing predictably /s
My take away was that SSDs are somewhat easy to predict failure on. I'd take predictable failure over unpredictable any day.
not that this is a rule, i've seen hdds fail instantly for no reason as well, and flash media throw a massive wobbler but still be recoverable. but in my experience this is not the normal behaviour.
but who cares as long as you have backups and a contingency plan?
[1] http://static.googleusercontent.com/media/research.google.co...
In any case, all the drives so far indicated they were destined to keel over via the SMART attributes long before it actually happened... Certainly long enough to buy a new drive and copy all the data, even for the less reliable TLC drive.
In fact even under a heavy workstation load you'd have enough time to save up money working a minimum wage part-time job, order the SSD when it goes on sale, wait for it to arrive via ground shipping, forget that you need an external SATA adapter, save up for that, order it, wait for shipping, then copy the data.
My original Intel X25-M G2, which I used for several years in my daily workstation, had around 4 TB total writes before I replaced it. That's two orders of magnitude lower than the apparent limit for these drives.
That's a really interesting metric. Can we call that the xenadu factor?
Our systems vendor is making a big push for SSD only systems for many reasons. Namely speed but the reduced costs for electricity and cooling are apparently significant too. There there is the form factor, they are going to be much more space efficient than spinning drives
Mirroring is really useful with spinning rust, where failures are (more or less) unpredictable and you need a spare to use while the first is replaced. I wonder if there's a better solution when the failure of the drive is more predictable that avoids having a second unit sitting there all the time - especially for applications where the data isn't absolutely critical.
and
> would not endanger data
in the same train of thought does not compute. Raid arrays do not protect your data. Only backups will do that.
In fact, striped raid arrays will tend to lose data faster than a drive by itself - when it comes time to calculate parity, they'll find an overlooked mistake and take out 2-3 more drives, writing off all the data on that cluster at once.
There is, however, a lesson I learned - never, ever build an array with drives of the same maker, model and batch, as they will have a tendency to fail at the same time for the same reasons. I did not build the array (I'd never do it), but it failed under my watch. Luckily, the first drive to go went one week before the second and the third and I had a plan-B.
I'm an overly cautious person when it comes to data so I'm still holding off - these results look promising enough to throw some of that caution to the wind.
If you use Windows 8, I've heard that doing something like this causes massive problems when updating Windows itself. It's been fine for Windows 7 though.
Using a junction point for a critical folder like that requires booting into a recovery mode and entering a bunch of incantations into a cmd window. And things will go sideways if you have to remove the Users drive at any point.
An easier course of action is to just use the Libraries functionality under windows and map each of those to write by default into your HDD. so most of my documents reside in D:\media\Documents instead of C:\Users\[blah]\Documents. Then you can also leverage the SSD speed for stuff in your AppData.
Compared to HDD, SSD failure modes are highly desirable and easy to handle.
http://arstechnica.com/science/2012/11/nand-flash-gets-baked...
'Verify disk' in Disk Utility from time to time. I usually get error messages and have to boot from the recovery partition to repair my system disk (Command-R).
According to the local Genius Bar, that's normal to a certain degree. For one MacBook Pro, I got the mainboard and the SSD repaired on warranty.
I am wondering if these issues are related to HFS+ or to the reduced reliability of SSDs …
Two of them are still going strong, one failed in very unique circumstances (and was probably recoverable by Samsung).