The SSD endurance test reached the 2 Petabte limit

[MrRiplEy[H]]

That's right folks, 2000 terabytes of writes and the Samsung 840 pro and Kingston HyperX 3k are still alive:

[Gman]

Heh, nice huh.  I don't have a Kingston, but have 2 840 Sams in the same size and one 830 in 128.  Good intel to know, for sure.  I figured the Samsung SSDs in my boxes would outlast the other surrounding hardware for the most part.

[Skuzzy]

The chart you just quoted is the "sequential read" test.  It does not surprise me if most any SSD would be fine with a fixed sequential write of that quantity.  Not much of a test as it caters to the strength of the SSD, but in reality, it is rare to have fixed size sequential writes.
Even at that soft read test, four of the units appeared to have failed.

Is there is a test which threads (4, at least) multiple writes, of random sizes (1K to 4K), while doing multiple reads of those files at a random size of 1K to 4K?  That would come closer to matching real world.

EDIT:  Does it show the actual number of operations?  That would yield a better measure of longevity when used in conjunction with the amount.

[MrRiplEy[H]]

The chart you just quoted is the "sequential read" test.  It does not surprise me if most any SSD would be fine with a fixed sequential write of that quantity.  Not much of a test as it caters to the strength of the SSD, but in reality, it is rare to have fixed size sequential writes.
Even at that soft read test, four of the units appeared to have failed.

Is there is a test which threads (4, at least) multiple writes, of random sizes (1K to 4K), while doing multiple reads of those files at a random size of 1K to 4K?  That would come closer to matching real world.

EDIT:  Does it show the actual number of operations?  That would yield a better measure of longevity when used in conjunction with the amount.

Yes they show random reads and writes too. Source: http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes

That's not a 'soft read test' they write the devices full and erase them as fast as they can muster. Every device in the test endured multiple times the advertised writes (the advertised endurance is usually 5-10 years of typical use), even the failed ones not to mention the two remaining ones. Writing an SSD full is multiple times harder for the device than regular use because in regular use the wear leveling algorithms ensure that if multiple small writes are done on a device the load is distributed evenly to the free clean blocks. This means that if you don't fill up your drive but do a lot of micro writes, your drive is going to last a very very long time despite it having only 4000-8000 write cycles per memory block (rated).

For the general consumer you can think of this like you have a storage house of 1000 six-packs of beer. You have to discard the six pack after you consume all of the cans. If you would drink every can one by one from each six pack you would have to throw out a lot of six packs. But if you drink a can here, can there you will spend an eternity before you have to dump even the first six pack (well, unless you are a total wino and drink your whole 1000x6 can lot every time at once like they're doing in this test).

[Skuzzy]

The OS breaks all write and read requests into 4K blocks (if the request is larger than that), as that is the memory page resolution for a virtual memory Intel system.  The only way to do actual larger blocks is to by-pass the operating system and do raw reads/writes, which do not need a filesystem.

If the driver supports scatter/gather, then the writes can be combined, if they are sequential on the media.  The purpose of using multiple threads is to mitigate the sequential nature of a single thread.  The operating system is always writing data, independent of the application.

By writing 4K chunks (or smaller), it bypasses the scatter/gather attempts of the driver, if applicable.  Using different size writes, below that (on 1K boundaries) imposes a higher degree of randomness in the testing, when using multiple threads.

Doing a full erase (filesystem level, or drive level?) and then filling it up again is not realistic at all.  Fill the drive with files, then update the files and change the size of those more closely resembles what happens in the reality.  Doing what they are doing is a general reliability test which cannot be related to real usage.

My interests lie in what would a real-life test be like compared to this static canned test.  Still need the actual count of operations performed to give the data some real meaning in terms of longevity.

[MrRiplEy[H]]

The OS breaks all write and read requests into 4K blocks (if the request is larger than that), as that is the memory page resolution for a virtual memory Intel system.  The only way to do actual larger blocks is to by-pass the operating system and do raw reads/writes, which do not need a filesystem.

If the driver supports scatter/gather, then the writes can be combined, if they are sequential on the media.  The purpose of using multiple threads is to mitigate the sequential nature of a single thread.  The operating system is always writing data, independent of the application.

By writing 4K chunks (or smaller), it bypasses the scatter/gather attempts of the driver, if applicable.  Using different size writes, below that (on 1K boundaries) imposes a higher degree of randomness in the testing, when using multiple threads.

Doing a full erase (filesystem level, or drive level?) and then filling it up again is not realistic at all.  Fill the drive with files, then update the files and change the size of those more closely resembles what happens in the reality.  Doing what they are doing is a general reliability test which cannot be related to real usage.

My interests lie in what would a real-life test be like compared to this static canned test.  Still need the actual count of operations performed to give the data some real meaning in terms of longevity.

The testing software handles its i/o through the operating system so the write load is similar to any other write load. This kind of testing is the worst case scenario for an SSD because it's being repeatedly 100% filled with data and then erased, which places multiple times more stress on the memory cells than your daily 80% reads 20% writes use that fills up typically less than 1% of the drive on daily basis.

If the drive can outlive this stress test it can walz through any regular use you can throw at it.

The average consumer writes 5-10 gigabytes a day to their drives. It will take the consumer 200 000 days to achieve the 2 petabyte mark of this test. That's 547 years of daily use. It's very likely that the drive will die to other causes way before it reaches the first 100 years.

[save]

I talked with a support guy that prep and replace  drives at work, we are using dell laptops so we can dock them.

What kills normally kills SSD drives is taking place during power-up ( not written data), ie electronic circuit failures. 
 

[Chalenge]

It would seem logical that the first ripple out of a (below-par) PSU will kill the SSDs onboard.

[guncrasher]

I am doing a real life test on my ssd evo than they cant do with their programs.  I have it sitting outside of the case on the carpet.  when I turn off the computer I unplug the ssd, then plug it back in when it comes back up.  I dont really have any date on it that I dont back up somewhere else.  just doing it literally for the kick of it.  as I kick the ssd once or twice when I play.

so far it is holding up.  as for the petabyte limit, I am not so sure as I am not a vegetarian.  I am just really having a kick out of how long the ssd will last.  so far no bad sectors and no lost data that I know of.


semp

[MrRiplEy[H]]

I am doing a real life test on my ssd evo than they cant do with their programs.  I have it sitting outside of the case on the carpet.  when I turn off the computer I unplug the ssd, then plug it back in when it comes back up.  I dont really have any date on it that I dont back up somewhere else.  just doing it literally for the kick of it.  as I kick the ssd once or twice when I play.

so far it is holding up.  as for the petabyte limit, I am not so sure as I am not a vegetarian.  I am just really having a kick out of how long the ssd will last.  so far no bad sectors and no lost data that I know of.


semp

You do realize that the SSD is suspectible to ESD shock just like any ohter computer component. Just don't come here bragging if/when your carpet zaps the drive with static and it dies. But it's funny that you chose the most powerful and long lasting media of your computer to be the usb backup lol. Or are you hotplugging it with sata also, without a hotplug bed? Prejudice is hard to get by I guess.

[MrRiplEy[H]]

It would seem logical that the first ripple out of a (below-par) PSU will kill the SSDs onboard.

Just as logical as the ripple kills any component onboard, like the control board of your spinning hdd.

We have a server running mysql databases (around 1 Tb) on Samsung 840 pros. Not a single hiccup for 2 years. On the other hand we haven't had a SAS drive break yet either but let's see.

[Chalenge]

Your systems are not the typical PC bought online or from Best Buy either. The problem is that low end PC systems have PSUs that are time bombs when it comes to SSDs. Your typical HDD is not anywhere near as sensitive as an SSD is.

[MrRiplEy[H]]

Your systems are not the typical PC bought online or from Best Buy either. The problem is that low end PC systems have PSUs that are time bombs when it comes to SSDs. Your typical HDD is not anywhere near as sensitive as an SSD is.

And you base your claim to which data exactly? Source of information please. It defies logic that the same integrated circuits that control SSDs would magically be more sensitive than those controlling spinner hdds. To me it seems that people are really stuck with the myth of unreliability caused by early production runs firmware problems that bricked many drives. That was entirely a software bug, not a hardware fault.

[Skuzzy]

And you base your claim to which data exactly? Source of information please. It defies logic that the same integrated circuits that control SSDs would magically be more sensitive than those controlling spinner hdds. To me it seems that people are really stuck with the myth of unreliability caused by early production runs firmware problems that bricked many drives. That was entirely a software bug, not a hardware fault.

The power driving the hard drive motor(s) are all regulated and filtered on the HD circuit board.  The R/W heads are also regulated and filtered.  Transient power transitions can cause a lot of problems, for hard drives, due to the density they are packing data today.

The SSD memory circuits take power directly from the power supply of the computer.  Some have a capacitor to help modulate any transient voltage variations, but most do not.  There is no real need for it due to how the device stores data, but it can lead to damage of the device.

Take a meter and read the resistance across the circuits.

[MrRiplEy[H]]

The power driving the hard drive motor(s) are all regulated and filtered on the HD circuit board.  The R/W heads are also regulated and filtered.  Transient power transitions can cause a lot of problems, for hard drives, due to the density they are packing data today.

The SSD memory circuits take power directly from the power supply of the computer.  Some have a capacitor to help modulate any transient voltage variations, but most do not.  There is no real need for it due to how the device stores data, but it can lead to damage of the device.

Take a meter and read the resistance across the circuits.

If this was a real world problem, the designers would have taken action already. It is not obviously. SSDs have 3-5 years warranties, you think the OEMs would intentionally make devices that are prone to catastrophic failure? Come on folks, you're not making any sense whatsoever. If anything SSDs have superior endurance because they lack any moving parts.