On Thu, 2011-01-13 at 20:19 +0100, Steve wrote:
I would not use MLC in a server environment. SLC has much better program/erase cycles per cell.
I wouldn't be overly worried about the underlying medium.
I'm more worried about the translation layer they use on top of it, to make it pretend to be spinning rust. It is essentially a file system, on top of which you are expected to layer another file system. Not particularly efficient, but at least TRIM addresses one of the biggest inefficiencies of that gratuitous extra layering.
The inefficiency is one thing, but it's the reliability that worries me. It's generally accepted that it takes at least 5 years for a file system implementation to truly reach maturity. And that's for open source code that you can debug, on a medium that you can access directly to do diagnosis and data recovery.
But what we're talking about here is a file system implemented inside a black box where you can't do any of that. And what's more, they keep changing it. Even if you manage to find some device that passes your testing, you may find that the next batch of the *same* device (from your point of view) actually contains completely different software *and* hardware if you take it apart.
These translation layers are almost always a complete pile of crap. Especially in the face of power failures, since they so often completely fail to implement basic data integrity features (the same kind of journalling features that also have to be implemented in the 'real' file system on top of this fake disk).
The best way to use flash is to have a file system that's *designed* for use on flash. The only problem with that is that it wouldn't work with DOS; you can't provide an INT 13h DISK BIOS handler to use it...
-- dwmw2