On Fri, Jan 1 at 21:21, Erik Trimble wrote:
That all said, it certainly would be really nice to get a SSD controller which can really push the bandwidth, and the only way I see this happening now is to go the "stupid" route, and dumb down the controller as much as possible. I really think we just want the controller to Do What I Say, and not try any optimizations or such. There's simply much more benefit to doing the optimization up at the filesystem level than down at the device level. For a trivial case, consider the dreaded "write-read-write" problem of MLCs: to write a single bit, a whole page has to be read, then the page recomposed with the changed bits, before writing again. If the filesystem was aware that the drive had this kind of issue, then in-RAM caching would almost always allow for the avoidance of the first "read" cycle, and performance goes back to a typical Copy-on-Write style stripe write.
I am not convinced that a general purpose CPU, running other software in parallel, will be able to be timely and responsive enough to maximize bandwidth in an SSD controller without specialized hardware support. This hardware support is, of course, the controller that exists on modern SSDs. Drive vendors abstracted these interfaces a long time ago, creating Integrated Drive Electronics (IDE). Bringing all of that logic back up into the CPU would likely not help meaningfully. Yes, it would likely be cheaper, but I doubt it would be faster or more reliable. I also am not convinced that your described RMW semantics are used in any modern NAND devices. Those problems were solved years ago. The granularity of the implementation has implications on performance in some workloads, but I believe only those old JMicron-based SSDs did block-level RMW, and hence wound up doing about ~2-3 IOPS in random workloads with MLC drives. SSDs (with good controllers) really strut their stuff when in-RAM caching isn't working anyway. If in-RAM was good enough, then why bother with SSD? Just have a spun-down rotating drive at 1/5th-1/15th the cost. --eric -- Eric D. Mudama edmud...@mail.bounceswoosh.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
