I've written up a blueprint with a rough sketch of how to take advantage of alternative storage interfaces. I am very happy to see that several f them have emerged over the past year or two: - fusionio's KVMKV is a key/value interface for their flash products - seagate's kinetic is a key/value interface for their new ethernet-based drive Also, leveldb is pretty great for many workloads when run on a tranditional disk/fs. The good news is a lot of the existing work that went into support omap looks to be reusable here. Some new functionality and refactoring is needed, though, particularly when it comes to storing object data (the file-like bag of bytes portion) as key/value pairs. The blueprint is here: http://wiki.ceph.com/01Planning/02Blueprints/Firefly/osd%3A_new_key%2F%2Fvalue_backend Haomai Wang has done some prototyping work already to accomplish some of this. I'm suggesting a few changes to his current approach: mainly, using DBObjectMap so that we can support clone. Also, I think we need to go a step further and handle large objects by striping data over lots of key/value pairs, as most of the new key/value interfaces limit values to 1MB. One of the big promises of this work is that we should be able to avoid the journal completely, which will mean avoiding the double write for more efficient backends. It will also be usable on conventional hardware as leveldb will be the reference k/v backend. If you're interested, pelase read it over, and add any detail or questions that should be included in the blueprint and/or discussed during the CDS session in a couple weeks! sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
