Some of the content on this page is in MathML. If your browser has trouble displaying any mathematical notation below you might find the PDF transcript of this page more helpful. There is also a collection of mathematical articles on this site, which should include this one. Additionally there is an ebook version of this page as well as an ebook version of the aforementioned collection of mathematical articles.
No, you won't kill your SSD anytime soon. Seems hard to find actual, crunched numbers though.
Ever wonder how long your shiny new SLC SSD will last? It's funny how bad people are at estimating just how long "100,000 writes" are going to take when spread over a device that spans several thousand of those blocks over several gigabytes of memory. Not to mention even newer drives that can take even more of a beating before going down. So yeah, let's crunch some numbers for that:
Note how I crunched numbers with the full 6Gbit/s throughput of SATA 3.0. We don't actually have drives that can deliver that kind of throughput, much less sustained for several years. You also typically won't find any natural scenario where you'll keep writing gigabytes of random data to an SSD like that. And by "that" I mean "sustained for days, months or years." And OS write caching hasn't been taken into consideration either.
As for the "10% Threshold" line, that's because SSDs typically contain about 10% of spare blocks hidden from the OS and used to replace dead blocks on the drive transparently. You typically won't find dead blocks in your fsck before that threshold is reached. Individual drives may contain fewer or more spares, but 10% seems a solid average at this time.
Net result: next time someone says "I wouldn't put my swap/log files on that flash drive," you'll know better. Might be a good idea to link this article for them while you're at it. Although I do have to admit that I had to make a few assumptions to plot those graphs here, but see below...
As a few helpful comments on slashdot pointed out, I have in fact only considered SSDs using SLC NAND chips. That's because, personally, I've only ever bought high-end SSDs, so it kind of came natural to me. I took the 100k P/E cycle estimate from this here datasheet, section 1.5 'Product Features'. As for the 1M stat, I assumed those for 'newer' SLCs following this press release.
A lot of consumer grade SSDs use MLC NANDs or worse, which will fry out a lot sooner. But then you probably still won't be writing to those constantly at speeds the drive doesn't even support, now would you? In any event, the calculations below should work for those as well, just plug in fewer erase cycles and a lower maximum throughput into the equations.
As with all things in life, there's always several ways to calculate estimates. Personally, I think every graph that doesn't describe how it was calculated is worthless - so let's see how I came up with those two above.
Flash drives and SSDs only degrade when actually written to. More specifically we can assume they degrade during a block erase operation, as flash chips need to be erased in order to be written to. So in order to estimate the life span of an SSD we have to estimate the number of erased blocks for a given time span.
Since we're trying to make a point here, we'll use the theoretical maximum write speed we could possibly run across at this point: the maximum link speed for SATA 3.0, which happens to be larger than any other relevant interface or drive speed so it's a solid upper bound.
Note: the original article did not take 8b/10b coding as used by SATA 3.0 into account, which decreases the throughput by 20%. The current graphs have been updated to reflect this new maximum throughput.
For the calculations we'll assume the following:
This seems a reasonable estimate given typical contemporary flash chips.
The drive firmware should be able to compensate for suboptimal writes well enough to bundle small writes together to fill up whole erase blocks. At peak throughputs this results in the drive needing to erase a block at a rate of:
Notice that this rate decreases with the write throughput, meaning that at more realistic throughput levels the drive will have to erase fewer blocks than that per second. I'd assume that the higher throughput we're using for our calculations would thus compensate for a suboptimal write bundling algorithm in the drive's firmware.
I seem to have trouble finding accurate statistics for this rather important metric. Contemporary flash chip descriptions seem to indicate an average of either 100,000 or 1,000,000 writes before a given block is likely to be dead. Unfortunately, most specification sheets on SSDs seem to omit the definition of "average" here. Thus I'll simply assume that number to be based on a Gaussian distribution and further assume a somewhat generous standard deviation of 10%.
This means that we should be able to use the following formula - a variant of the cumulative distribution function - to estimate the probability of a given block to be broken after a given number of writes to it:
Note that erf is the Gauss error function, writes is the number of writes performed to a block and write count is either 100,000 or 1,000,000 - we'll crunch the numbers for both.
The formula above gives us the probability of blocks in a given erase block to be broken after a given number of writes. Obviously any given SSD will have more than one erase block, and that number is easily calculated as:
To find out how many blocks are broken after a given number of writes, we'll further assume that we have a perfect write leveling algorithm on the drive's firmware. That means that no matter which (logical) block we write to in software, the drive will distribute the erase and write operation to a truly random physical block. This greatly simplifies calculations by allowing us to apply the law of large numbers to our model, and it shouldn't be far off either - that is, after all, the purpose of write leveling.
With this additional assumption we use the following formula:
If we plot this with writes on the x axis, then the y axis will be average number of broken blocks - that is we're essentially having (number of erase blocks) separate probability experiments running in parallel, which multiplied by the probability of an individual block breaking is the number of those blocks that have broken so far.
If we bring the previous resulting formulas together, we find that we simply need to scale our probability calculation by the number of erased blocks/time to get an estimate of how long we need to write to a drive before it starts breaking.
The resulting formula for our plot is thus:
Substituting variables yields:
This plot indicates how many of the drive's erase blocks have broken so far, on a scale from 0 (none) to 1 (all of them) on the y axis and the elapsed time on the x axis. Interestingly, the exact erase block size we used to come up with the formula is not needed for this calculation.
The plots include a guiding line at 0.1 - this is because SSDs are built with approximately 10% spare blocks to compensate for burnt out flash chips. After 10% of the blocks are broken you'll start to "see" them in software - before that you won't notice anything because the drive firmware will hide them. Or at least it's supposed to, anyway.
We can now use a tool like gnuplot to render the plot with appropriate variables subsituted, e.g. like this for a 64GB drive at 100k writes:
speed=6
size=64
writecount=100000
set yrange [0:1]
set xrange [800000:20000000]
plot (0.5*(1+erf(((x*(speed*1000*1000*1000/10)/(size*1000*1000*1000))-writecount)/sqrt(2*((writecount*0.1)**2)))))
Alternatively, we could also have plotted the number of broken blocks directly:
Unfortunately this plot makes it harder to compare different SSD models, as the number of erase blocks depends on the size of the device. I still thought it'd be worth mentioning.
Last Modified: 2013-03-03T18:45:00Z
Since you came this far, why not follow jyujinX on Twitter