TR's SSD endurance test

[jtr1962]

It sounds like all of these drives stand a good chance of making past the 1 petabyte mark with flying colors. This test puts to rest any lingering worries I might have had about SSDs not being reliable. I already felt they were more reliable than spinning disks, but I had lingering worries about wearout until now. By the time my SSD wears out at the rate I'm writing to it, we'll have warp-driven starships.

 

[Howell]

What is the currently recommended cushion to require for free space when sizing a drive floor an installation? My understanding is that the overprovisioning space is not counted in the listed drive size. Are there other considerations to be accounted for special to an SSD or just treat it like a spinning disk?

 

[ddrueding]

I just stick them in and don't worry about it. The only issues I run into are space related (Windows Updates take tons of space over time).

 

[LunarMist]

I have experienced slowdowns when drives are becoming full.

 

[Howell]

Futher research revealed this: http://www.anandtech.com/show/6489/playing-with-op.

Anand's testing of those 3 drives indicates that the most consistent IO across the drive is achieved if you intentionally do not use 25% of the accessible part of the drive.

I'm still looking into whether the research is still relevant as it is more than a year old. As you can tell I'm a little behind most everyone.

 

[P5-133XL]

600TB update

 

[Chewy509]

Thanks for the update. Very interesting and pleasantly surprised that they are lasting so well.

I've reread the whole series, and there is 1 concern I have that these tests may not reflect a real world environment.

According to the first article, there is only 10GB of static data on the drives, however my real world experience usually pegs this at 50-70% static data in single drive setups. (So for a 200GB drive, I would expect up to 150GB of static data, usually movies, music, games). Why does this matter? Well, the big question at the moment with some controllers and firmware is, does the wear leveling code move static blocks around to allow lesser used blocks for more volatile data to be placed? (So far, I haven't been able to find any answers to this). Would these drives perform as already demonstrated by these tests with being filled with 70% static data? I think this is also a concern for people using SSDs in servers as well... The have been a number of reviews/studies that clearly demonstrate that most data held of servers is largely static in nature...

For multi-drive setups used by enthusiasts , the amount of static data isn't as much of an issue, as the static data will tend to sit on a conventional HDD and not the SSD. But since a lot of laptops are coming with SSDs (and there are a few desktops/all-in-ones/NUCs coming with SSDs), how well does this test represent that market?

 

[Chewy509]

Not deriding the tests being performed, but it certainly has raised more questions than answers (which is an excellent thing).

 

[mubs]

Very valid points, Chewy.

 

[Howell]

Well, the big question at the moment with some controllers and firmware is, does the wear leveling code move static blocks around to allow lesser used blocks for more volatile data to be placed? (So far, I haven't been able to find any answers to this).

I've enjoyed getting up to speed on SSDs and the benefits/disadvantages. Thanks.

Static wear leveling has such greater benefits for longevity and the cost can be mitigated by the over-provisioned area I can't imagine why a design would do otherwise. Micron: TN-29-42: Wear-Leveling Techniques in NAND Flash Devices

Notes of interest:

• Flash writes happen one 4KB page at a time but erases happen blocks at a time with 128 pages in a block. Moving data from pages in a block that needs to be overwritten is part of the definition of garbage collection.
• This paper from LSI says that the minimum amount of over-provisioning is based on the difference between GB and GiB. Which leads to the 7% figure we often see.
• The introduction of the TRIM command makes HD forensics very difficult if not impossible. Even a quick format will tell TRIM that the whole drive should be erased.

 

[Chewy509]

Static wear leveling has such greater benefits for longevity and the cost can be mitigated by the over-provisioned area I can't imagine why a design would do otherwise.

Thanks for the link, but it remains, how many devices actually implement static wear leveling? (The costs are slowed writes and a higher performance controller is needed to offset slower writes, not to mention a proven firmware implementation, something which we all know companies will do anything to save a few cents on the BOM). I certainly hope that most decent SSDs do implement static wear leveling making my concerns mute.

The introduction of the TRIM command makes HD forensics very difficult if not impossible. Even a quick format will tell TRIM that the whole drive should be erased.

Something that we are now seeing in digital forensics with NAND, if chip-off acquisitions, where the NAND is removed from system board and controller, and is read independently... (Most NAND have JTAG pins for debugging purposes).

What has been seen is that a lot of device will not erase pages on a TRIM issue, but just mark the page as unused in the FTL/FTT (Flash Translation Layer/Flash Translation Table). Similarly, even with a SECURE ERASE command, not all controllers actually erase/overwrite the NAND itself. (Some that use encryption simply update to a new 3DES/AES key and call it done, but for giggles the old 3DES/AES key has been found with the NAND that accompanies the controller as well, making secure erase on those devices next to useless, and others simple wipe the FTL/FTT).

So in regards to Forensics, not all is lost... (We currently have a project at work that is doing chip-off acquisition on an iPhone4 - FYI, the phone was run over by a car, but the NAND itself seems ok). The cost for chip-off acquisition isn't as high as one would expect. (Sub $1000 in hardware and software that will target about 60% of the NAND on the market, providing you are willing to do some DYI).

 

[Howell]

What has been seen is that a lot of device will not erase pages on a TRIM issue, but just mark the page as unused in the FTL/FTT (Flash Translation Layer/Flash Translation Table).

Strange. This would defeat the whole speed benefit of TRIM; to erase blocks in advance of needing them rather than just in time. Marking the page as unused is the normal process so either the TRIM command was not correctly issued or there is unexpected (to me) lag between issuance and completion. How long between issuance of the command and drive power-off? What OS/filesystem? What SATA revision was the drive? Maybe this is a function of the non-queued nature of the current TRIM command and will become more consistent with the introduction of the Queued Trim Command in SATA3.1.

 

[Chewy509]

Marking the page as unused is the normal process so either the TRIM command was not correctly issued or there is unexpected (to me) lag between issuance and completion.

You seem to forget option 3, the TRIM command in firmware was never implemented properly or according to spec.

Having started working in the forensic's field (my main employment currently is tool development for digital forensics), is that a lot of what we do is relying on the half-arsed job other developers do to acquire evidence... eg improper TRIM commands, OS's not cleaning up meta-data correctly, or overwriting deleted files with zeroes, deleting partitions only removes the partition entry from the partition tables, etc.

We currently have a project at work that is doing chip-off acquisition on an iPhone4 - FYI, the phone was run over by a car, but the NAND itself seems ok

We successfully read the NAND, but alas the phone was factory reset before it was run over, so we weren't able to get anything off the phone... But we learnt a lot in the process...

 

[Howell]

You seem to forget option 3, the TRIM command in firmware was never implemented properly or according to spec.

Argh, its always option 3! Thanks for a good discussion Chewy! Case in point, I looked up the SATA revision for the drives I recently purchased and it only lists SATA 6Gb/s. An optimistic man would say this is the marketing information a layman would find important in the limited space allotted. A pessimist would say that's the best they could legally say.

 

[Chewy509]

A pessimist would say that's the best they could legally say.

This...

The other thing you need to remember is that many parts of the ATA-8 specification (aka SATA specification for 3Gbps/6Gbps) are marked as optional (for example the Compact Flash extension) or implementation details undefined (particularly with the cache management functions in non-secure mode). Whilst the ATA-8 specification costs $$$, you can get the draft copies of the spec for free... (https://www.google.com.au/search?q=draft+ata-8+standard ) if you want all the gory details. (TRIM is implemented as of the DATA SET MANAGEMENT command).

 

[P5-133XL]

1 PB (1000 TB) update

3 dead, 3 still alive!

 

[Mercutio]

The utter lack of warning of failure on the 840 is definitely in line with my experiences.

 

[LunarMist]

The utter lack of warning of failure on the 840 is definitely in line with my experiences.

That is still very impressive, approximately 3600 full write cycles from TLC. Did your drives die earlier than that?

 

[Chewy509]

Thanks for the update.
Interesting that the Intel and Kingston bricked themselves when write's started failing, so limited opportunity to get data off the drive when writes have been exhausted...

 

[P5-133XL]

Do note that there was 25+ TB of warning. For most people that would be an enormous amount of time.

 

[jtr1962]

Do note that there was 25+ TB of warning. For most people that would be an enormous amount of time.

Given my usage patterns that's somewhere north of a decade-more than enough time I think to get my data the drive.

 

[Chewy509]

Do note that there was 25+ TB of warning. For most people that would be an enormous amount of time.

Agree 100%. But I was under the impression, that once write limits were reached, the drive would remain in read-only mode indefinitely and not brick themselves at some point in the future (and I suspect many users would expect the same sort of thing).

 

[P5-133XL]

Agree 100%. But I was under the impression, that once write limits were reached, the drive would remain in read-only mode indefinitely and not brick themselves at some point in the future (and I suspect many users would expect the same sort of thing).

I won't disagree, because I think you are correct. I really can't see the value of bricking anything. Read-only mode should be enough and at least a RAW mode to get whatever data you can off it, even if it is bad. I'm just saying you do have plenty of time to remove your data from the start of the warning to any problem stage at least for two of the failed drives.

 

[CougTek]

I won't disagree, because I think you are correct. I really can't see the value of bricking anything.

It can be quite useful when you want to dispose of drives with sensitive data that have gone through their useful life.

 

[Chewy509]

It can be quite useful when you want to dispose of drives with sensitive data that have gone through their useful life.

That's what thermite is for! (disposing of drives with sensitive data).

 

[P5-133XL]

I am old school: A hammer.

 

[LunarMist]

Thanks for the update.
Interesting that the Intel and Kingston bricked themselves when write's started failing, so limited opportunity to get data off the drive when writes have been exhausted...

There is an opportunity every day to backup the data.