Hi Haomai, <<inline. Thanks & Regards Somnath
-----Original Message----- From: Haomai Wang [mailto:haomaiw...@gmail.com] Sent: Thursday, September 11, 2014 7:28 PM To: Somnath Roy Cc: Sage Weil; ceph-users@lists.ceph.com; ceph-de...@vger.kernel.org Subject: Re: Regarding key/value interface On Fri, Sep 12, 2014 at 9:46 AM, Somnath Roy <somnath....@sandisk.com> wrote: > > Make perfect sense Sage.. > > Regarding striping of filedata, You are saying KeyValue interface will do the > following for me? > > 1. Say in case of rbd image of order 4 MB, a write request coming to > Key/Value interface, it will chunk the object (say full 4MB) in smaller > sizes (configurable ?) and stripe it as multiple key/value pair ? Yes, and the stripe size can be configurated. [Somnath] That's great, thanks > > > 2. Also, while reading it will take care of accumulating and send it back. Do you have any other idea? [Somnath] No, I was just asking By the way, could you tell more about your key/value interface. I'm doing some jobs for NVMe interface with intel NVMe SSD. [Somnath] It has the following interfaces. 1. Init & shutdown 2. It has container concept 3. Read/write objects, delete objects, enumerate objects, multi put/get support 4. Transaction semantics 5. Range query support 6. Container level snapshot 7. statistics Let me know if you need anything specifics. Thanks & Regards Somnath > > > > Thanks & Regards > Somnath > > > -----Original Message----- > From: Sage Weil [mailto:sw...@redhat.com] > Sent: Thursday, September 11, 2014 6:31 PM > To: Somnath Roy > Cc: Haomai Wang (haomaiw...@gmail.com); ceph-users@lists.ceph.com; > ceph-de...@vger.kernel.org > Subject: Re: Regarding key/value interface > > Hi Somnath, > > On Fri, 12 Sep 2014, Somnath Roy wrote: > > > > Hi Sage/Haomai, > > > > If I have a key/value backend that support transaction, range > > queries (and I don?t need any explicit caching etc.) and I want to > > replace filestore (and leveldb omap) with that, which interface you > > recommend me to derive from , directly ObjectStore or KeyValueDB ? > > > > I have already integrated this backend by deriving from ObjectStore > > interfaces earlier (pre keyvalueinteface days) but not tested > > thoroughly enough to see what functionality is broken (Basic > > functionalities of RGW/RBD are working fine). > > > > Basically, I want to know what are the advantages (and > > disadvantages) of deriving it from the new key/value interfaces ? > > > > Also, what state is it in ? Is it feature complete and supporting > > all the ObjectStore interfaces like clone and all ? > > Everything is supported, I think, for perhaps some IO hints that don't make > sense in a k/v context. The big things that you get by using KeyValueStore > and plugging into the lower-level interface are: > > - striping of file data across keys > - efficient clone > - a zillion smaller methods that aren't conceptually difficult to implement > bug tedious and to do so. > > The other nice thing about reusing this code is that you can use a leveldb or > rocksdb backend as a reference for testing or performance or whatever. > > The main thing that will be a challenge going forward, I predict, is making > storage of the object byte payload in key/value pairs efficient. I think > KeyValuestore is doing some simple striping, but it will suffer for small > overwrites (like 512-byte or 4k writes from an RBD). There are probably some > pretty simple heuristics and tricks that can be done to mitigate the most > common patterns, but there is no simple solution since the backends generally > don't support partial value updates (I assume yours doesn't either?). But, > any work done here will benefit the other backends too so that would be a > win.. > > sage > > ________________________________ > > PLEASE NOTE: The information contained in this electronic mail message is > intended only for the use of the designated recipient(s) named above. If the > reader of this message is not the intended recipient, you are hereby notified > that you have received this message in error and that any review, > dissemination, distribution, or copying of this message is strictly > prohibited. If you have received this communication in error, please notify > the sender by telephone or e-mail (as shown above) immediately and destroy > any and all copies of this message in your possession (whether hard copies or > electronically stored copies). > -- Best Regards, Wheat _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
