Re: Intel's X25-M SSD

I have been paying close attention to the recent SSD performance/price changes with a keen eye to server performance on various workloads and applications.

The real barrier is in the controller design, and IP surrounding that.  All flash products with any amount of wear-leveling map logical addresses to physical flash addresses dynamically.  An intelligent controller, with enough processing power and RAM (Intel's drive has 16MB of DDR SDRAM) and an intelligent design can translate ALL random writes into a sequential stream.  With enough overprovisioning, the erasing and cleaning that goes on in the background will have very minimal impact.  One thing many people will claim about a SSD is that the erasing and block management will get slower as the drive becomes more full.  This is incorrect -- from the point of view of any block device it is always 100% full, it is not privy to the file system notion of 'free space'.  Addresses are simply overwritten, which makes blocks that previously mapped to those addresses available for writing.  By definition, every write is an overwrite.

This paper, is very enlightening:
http://research.microsoft.com/users/vijayanp/papers/ssd-usenix08.pdf

Given Intel's particular strenghts and engineering resources, its not a surprise that they are among the first to make a design like this (FusioIO seems to have solved the random write performance issue as well ?).  But as the review you provided links to demonstrates, it is this IP that will provide the performance gains necessary for flash performance to be hands down better than all drives, for all workloads, all the time. It is the same IP that will provide the most longevity and reliability.

Also of note for others reading this thread, the review was for Intel's "mainstream" device, not the "enterprise" one.  The enterprise one claims 3300 random 4k writes/sec and over twice the write throughput.  I'm sure it will also cost twice as much for less capacity.

Of particular interest in the short term may be using cheaper, read-biased flash drives for ZFS L2ARC caches for a database -- it may be like running with a couple hundred extra gigs of RAM, but you can still use slow, big drives for mass storage.  The price is prohibitive for putting your whole db on flash if it is not a small one, but this is not true if you're just talking about cache devices or xlogs or temp space.
http://blogs.sun.com/brendan/entry/test