On Fri, Sep 12, 2014 at 9:46 AM, Somnath Roy <Somnath.Roy at 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. > 2. Also, while reading it will take care of accumulating and send it back. > Do you have any other idea? By the way, could you tell more about your key/value interface. I'm doing some jobs for NVMe interface with intel NVMe SSD. > > > Thanks & Regards > Somnath > > > -----Original Message----- > From: Sage Weil [mailto:sweil at redhat.com] > Sent: Thursday, September 11, 2014 6:31 PM > To: Somnath Roy > Cc: Haomai Wang (haomaiwang at gmail.com); ceph-users at lists.ceph.com; > ceph-devel at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ceph.com/pipermail/ceph-users-ceph.com/attachments/20140912/bad1ef61/attachment.htm>
 |