[Nottingham] So how quickly can you kill an SSD?

[Martin]

On 22/10/13 12:08, Jason Irwin wrote:
> Not quickly at all it seems. Unless you do something *really* daft of
> course.
> 
> http://hblok.net/blog/posts/2013/03/03/concerns-about-ssd-reliability-debunked-again/
> 
> What I like about this article is that it works through the methodology,
> so you can plug in your own numbers and figure out what will/will not
> work for you.

Thanks for that and a very good article.


Times change... Especially so for the trick of "wear levelling" that has
been greatly improved for the more recent SSDs...

I looked at this in the context of the problem of "write amplification"
if you misalign your data off the underlying hardware boundaries. Hence
the convoluted posting:

Howto HDD and SSD Alignment
http://nottingham.lug.org.uk/2011/09/howto-hdd-and-ssd-alignment/608

That was all back in what you might call the 'bad old days' when SSDs
were new and unknown and the manufacturers were all ridiculously
secretive about what they were doing and how. Linus about that time very
controversially told the kernel world "not to worry about it" in that
all the low level fun was a hardware/firmware detail that should be
transparent to the rest of the world...

OK... So not quite... There's since been a few fixes on both sides of
the SATA pipe...

The SSD controllers and firmware has greatly improved and usually they
now include a respectable cache memory to allay performance and flash
killing write-amplification problems.

Meanwhile from the kernel side, we now have "TRIM" ("discard"),
filesystem delayed allocation, and even some SSD sympathetic
log-structured file systems.

Also, the various disk partition utilities have seen their first revamp
in decades to now newly understand disk partition placement alignment.
Some voodoo arcane alignment for LVM has been fixed also. Various
partition programs now align to a good default of 1 MiB or 2 MiB
boundaries. In gdisk, you can now easily set that rather than doing the
old "CHS" voodoo numbers tricks.

All this has also been spurred on by all new HDDs now using 4kiB
sectors. (The old standard was 512 bytes sectors.)



Phew!

*The practical upshot of all that* ?

Taking any recent SSD and a new distro install, a typical user need not
even know what a sector is. All the defaults should work nicely. No
worries. No appreciable wear-out. The SSD should last longer than the
user. :-)

However, if you are running servers with pathological usage with virtual
machine images and databases, then you should already know enough to not
be too flash-killing silly! ;-)


And for a real-world comparison:

I've recently destroyed (write failed and firmware set to read-only) my
second USB 16GB memory stick for one multi-site low powered webserver.
Despite great care for the partitioning and the use of ext4, all
carefully aligned, they are lasting about two years a time of continuous
use. (Both failed after a kernel update... Coincidence?)

The USB memory stick fails may even be due to bit rot rather than write
wear-out: I've noticed backups checks fail once or twice a year for old
data that has never (or rarely) been rewritten. (Rewriting the afflicted
file solves that.)

Another two server systems using SSDs are of no worry whatsoever,
including having swap space on there. The daily GBytes writes suggest
that the systems will be obsolete and scrapped before the SSDs should
wear out.

... Which is why I've never bothered finishing a follow-on article to
the old rambling post of SSD confusion. (Then again, the old article is
a good investigative read!)


One technical detail to note for SSDs still: An important performance
marker is how fast they operate for 4kiB read/write.

However, their underlying structure usually favours 8kiB, 16kiB or 32kiB
block sizes for writes. The only headache there is how best then to fit
in what block size to use for a raid setup to avoid crass unwanted write
amplification... (But who uses SSDs in raid?...)


Hope of interest,
Martin


-- 
- ------------------ - ----------------------------------------
-    Martin Lomas    - OpenPGP (GPG/PGP) Public Key: 0xCEE1D3B7
- martin @ ml1 co uk - Import from   hkp://subkeys.pgp.net   or
- ------------------ - http:// ml1 .co .uk/martin_ml1_co_uk.gpg