Sage, I have some questions regarding to the key/value backend work. What is the motivation to work on this? (or what is the problem we want to solve?) 1) to use the new interface thus we can bypass all the OS layer thus get a short latency? 2) or to leverage some new primitive e.g. the atomic write thus to simplify the code writing? There are several different possibilities to use future NVM technology - NVM.FILE, NVM.BLOCK, PM.XXX http://snia.org/sites/default/files/NVMProgrammingModel_v1r10DRAFT.pdf Even for openNVM thing - there are other usage model than k/v. Do you have any typical usage model for this? -jiangang =================== From: Sage Weil <sage <at> inktank.com> Subject: new ceph-osd key/value backend Newsgroups: gmane.comp.file-systems.ceph.devel Date: 2013-11-09 10:09:52 GMT (4 weeks, 3 days, 16 hours and 39 minutes ago) 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 ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
