Flash Destroyer Tests Limit of Solid State Storage 229
An anonymous reader writes "We all know that flash and other types of solid state storage can only endure a limited number of write cycles. The open source Flash Destroyer prototype explores that limit by writing and verifying a solid state storage chip until it dies. The total write-verify cycle count is shown on a display — watch a live video feed and guess when the first chip will die. This project was inspired by the inevitable comments about flash longevity on every Slashdot SSD story. Design files and source are available at Google Code."
Interesting! (Score:4, Interesting)
Re:Interesting! (Score:1, Interesting)
Yes, its nice to finally get some independent data on this. It would also be nice to try this tool on spinning platter disks. People tend to forget that they also only endure a limited number of cycles. From what I remember from the time before spinning platter disks had wear leveling implemented the number of writes was way lower than that of modern flash memory. (Or perhaps I was just unlucky.)
Re:Interesting! (Score:5, Interesting)
I would like to see a comparison with a mechanical drive doing the same thing in parallel.
While the Solid Sate has a theoretical Limited number of writes vs. the mechanical drive, it would be interesting to see what real world has to offer.
Re:live stream (Score:3, Interesting)
Doesn't multicast help any? Given a bunch of people who want to view the same exact stream, the server should be sending the same packets and letting the viewers' players deal with sync, starting at a key frame (and not in the middle of some crumbly diff frames), et cetera. With that, the server could just concentrate on the list of viewers' IPs, send packets far less often, and the /. arson fails.
Live streams, to me, seem easier than webpages because the viewer always wants the current frames of a live video but may want any portion of any other pages.
Re:Interesting! (Score:5, Interesting)
I'm just curious, why use sic in your own posts? Wouldn't you just correct whatever you are sic-ing?
IMHO, this kind of use of [sic] is perfectly valid. It means "this is not a typo, it's really how it is spelled" (literally "thus"). In this case it refers to an unusual word that may look like a misspelling of a more common word. However, it can also refer to a genuine misspelling, when you are referring to what somebody else wrote.
Re:Interesting! (Score:4, Interesting)
And honestly it's a pretty valid argument. This is definitely going to be informative, but I'm just as interested in how a particular SSD handles the flash blocks failing as when they fail. A SSD with flash that averages 1,000,000 writes before blocks start to fail but does it gracefully with little/no data loss could be better than one that averages 2,000,000 but goes out in a blaze of glory as soon as the first block fails.
Flash fails on write - if the write succeeds, you will be able to read it baring catastrophic events like ESD exposure.
Re:Interesting! (Score:1, Interesting)
Typically flash chips are shipped with bad blocks already on them. When they say 1,000,000 write cycles, it is caveatted with a number of blocks you should expect to go bad within that time frame. Also, when a block goes bad, it's not like it melts. It just means that you will get more bit errors than can be corrected based on its specifications. How that affects the data stored in there depends on what it is ... if it is a .wav file, no biggie, you'll just hear a blip. If it is used as a swap file, well, you very well may get an explosion.
Re:Interesting! (Score:3, Interesting)
Mechanical disks have lots of great failure modes.
My favorites are the ones that make loud sounds during the failure event. When a piece of the head breaks off, for example.. that thing bounces around in there like crazy when the drive is spinning around thousands of times per minute.
Re:live stream (Score:3, Interesting)
And which works great for IPTV solutions. The end points subscribe to a channel by setting their IP, and then the upstream router decides if it needs to do the same, heading further back until it hits another router that's got the channel already subscribed.
Similar for when you leave the channel. Once the router decides it's not got any clients for a given channel, it'll unsubscribe from it and those will bubble back.
Very elegant, imo.
Re:Interesting! (Score:4, Interesting)
One should not forget companies might have "chip lotteries", i.e. use chips that are less robust and cheaper to manufacture without majority of consumers knowing the difference.
They do this in the LCD monitor industry where they have "panel lotteries" that use cheaper parts and are not what is advertised due to consumer ignorance. See Article on Anand here about panel lotteries:
http://forums.anandtech.com/showthread.php?t=39226 [anandtech.com]
Re:Interesting! (Score:2, Interesting)
See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors, nor is it "perfect" in any sense of the word.
If you have a copy on write filesystem such as ZFS, changes might be written to new blocks.
It seems that in the future storage agents (or the SSDs themselves) might eventually evolve to relocate certain regions physically, in order to put rarely written data, or data that is 'stable' due to the existence of snapshots, onto the most worn sectors.
Once wear on the commonly written sectors exceeds certain ranges...
Re:Apples and hippos (Score:4, Interesting)
All of these ones: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010150636%201749646482&name=SLC [newegg.com]
Re:live stream (Score:3, Interesting)
It is very nice. And it was around for a long, long time before people started using it for everyday television (IPTV). We used to call it the Mbone [wikipedia.org].