I don’t think that white papers from the vendor prove much except that they thought about the issue, whether or not they did anything about it. Those are marketing pieces. I’d like to see some 3rd-party testing of the lifetime of SSDs under a WAL load on a really busy database.

If you believed Dell’s whitepapers, for example, every server they ship would be perfect.

Fusion IO does not use any memory based caching in front of the SSD. It also uses a capacitor for allowing all writes to drain in the event of a cold-power off scenario. I personally tested various combination’s of failure scenarios where the power was cut off during very high write workloads w/o any problems with data loss.

Greg, In terms of ranting, that’s all fine. Just go rant to the people you have a beef with not me. I don’t give a rats ass about your issues with site design and how they force people to sign up. Also, if your still interested in FusionIO you need to do some more homework. I suggest getting one in your hands an actually using it, they are very nice about loaner hardware so you can make accurate judgments.

The rest of you, thanks for taking the time to read and comment, it’s very much appreciated and enjoyed.

The unfortunate situation here is that most vendors ship their drives in configurations that aren’t safe for database use, and unless specific steps are made to correct for that write tests against the drive are not giving real-world results in that context. Note that Peter and several others on that other blog had the same concern, I’m not the only one who’s stuck on this point. I really don’t care about devices that perform well but without good write guarantees, so the first question I ask is not “how fast is it?” but instead “if the drive loses power, can data that’s been written and returned a successful fsync be lost?” The information on that blog suggests the default Fusion IO configuration gives the wrong answer to that question, meaning databases put there can get corrupted after a power outage, but there’s a lot of handwaving rather than hard data there too. I’m not a very trusting person, which applies equally to vendors and to people being critical of products; I don’t know what’s the real story here yet. But when you mention lots of data being cached in RAM, that sure sounds scary for writes being able to survive an outage.

Thanks for the clarification about their support site. From my perspective, making people go through registration hoops is still an odd decision that reflects on their business. A small company has enough hurdles to cross selling to enterprise customers already, they shouldn’t make life more difficult for buyers who want more technical information about the product. I suspect that’s driven by the fact that any access to the drivers is sitting behind a EULA agreement for legal reasons. I downloaded all their user guides, browsed the knowledgebase, and even poked through the driver source code briefly; wasn’t able to get any clarification on the write durability questions I still have about the device so far though.

The support site is free, there is no requirement to have bought anything. I have found Fusion IO to be an excellent vendor so far. Great support and help throughout our testing cycle. I think you are reading *way* too far into a company by looking at the (what you thought was closed) support site and making judgements. The Fusion I/O folks have been fantastic in terms of support.

In terms of durability, the Fusion I/O has only metadata in DRAM and has capacitors for the actual data pages. Pages are written one at a time. I am not privy to the actual algorithms used. I spoke to the folks over there about this directly. You might want to give them a call to clarify your blog post.

The Intel X25-E you mention in your blog is actually a SATA ‘drive’, where this is a card on the PCI-E bus. So the drivers don’t write down a storage chain with a faster ‘disk’. They write to the storage device directly. AKA: The Intel SSD is emulating a SATA drive.

My understanding is it’s simply NAND flash. The data is written to a temp space directly where the background process performs the final write.

This whitepaper addresses your concerns. I don’t have any reason to dispute it. The short answer is, likely longer than spinning disks. In our write duty cycle of this test, the whitepaper indicates for MLC flash about 5 years. But at our TPS rate who knows really. The good news is Fusion IO would start to take chips out of rotation at about 5 years as they fail and available free space would start to shrink. So it would not be a catastrophic event when they start to fail.

Here is the link to the whitepaper:
http://www.fusionio.com/PDFs/Whitepaper_Solidstatestorage2.pdf

What is the limited lifetime like in database terms? Like, how long could you use an SSD for a high-volume database (or for the WAL) before you had to replace it?

Did you leave the Fusion device in its default, non-durable state? See http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-vs-fusionio/ for more about that if you didn’t fool with it yet. I find all these write-cached SSD numbers academically interesting, but not really helpful for database use where you need fsync to actually force a physical commit.