Hi Matt, Can you please upstream the implementation you are mentioning?
Varada -----Original Message----- From: Matt W. Benjamin [mailto:m...@cohortfs.com] Sent: Thursday, February 26, 2015 5:26 AM To: Somnath Roy Cc: Varada Kari; Ceph Development; Sage Weil Subject: Re: Adding a proprietary key value store to CEPH Hi, We implemented an objectstore factory which does this, and could probably be upstreamed. Matt ----- "Somnath Roy" <somnath....@sandisk.com> wrote: > Yes, we will take care of both, thanks.. > > -----Original Message----- > From: Sage Weil [mailto:s...@newdream.net] > Sent: Wednesday, February 25, 2015 3:25 PM > To: Somnath Roy > Cc: Varada Kari; Ceph Development > Subject: RE: Adding a proprietary key value store to CEPH > > On Wed, 25 Feb 2015, Somnath Roy wrote: > > Sage, > > Yes, agreed.. > > But, since k/v store is already added and we are planning to derive > > > from that we didn't change that. Do you want us to implement entire > > > k/vstore to be a dynamically loadable along with the k/vdb > underneath ? > > Both would be nice. I confess I haven't looked closely at the EC > backend implementation, but I expect that this is quite simple: it's > just a matter of exposing a function that instantiates an instance of > the ObjectStore or KeyValueDB class, right? > > sage > > > > > > Thanks & Regards > > Somnath > > > > -----Original Message----- > > From: ceph-devel-ow...@vger.kernel.org > > [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Sage Weil > > Sent: Wednesday, February 25, 2015 6:46 AM > > To: Varada Kari > > Cc: Ceph Development > > Subject: RE: Adding a proprietary key value store to CEPH > > > > On Wed, 25 Feb 2015, Varada Kari wrote: > > > Hi Sage, > > > > > > Thanks. Will wait for your reply. > > > Meanwhile, Can I submit a blue print for this for next release? > > > > Yeah, definitely. > > > > FWIW the plugin layer I think will be most interesting going forward > is the ObjectStore level, not just the KeyValueDB level... > > > > sage > > > > > > > > > > Thanks, > > > Varada > > > > > > -----Original Message----- > > > From: Sage Weil [mailto:s...@newdream.net] > > > Sent: Tuesday, February 24, 2015 10:21 PM > > > To: Varada Kari > > > Cc: Ceph Development > > > Subject: Re: Adding a proprietary key value store to CEPH > > > > > > Hi Varada, > > > > > > On Tue, 24 Feb 2015, Varada Kari wrote: > > > > Hi Sage, > > > > > > > > We are trying to integrate a new proprietary key value store to > CEPH. To integrate this KV-store, which is a closed source shared > library, we propose a new class to CEPH called PropDBStore which does > a dlopen and imports the required symbols. This framework will help in > integrating vendor specific extensions to CEPH. > > > > > > > > The gist of the implementation is as follows. > > > > > > > > 1. Implement a wrapper around the proprietary KVStore. Let us > call it as KVExtension. This is a shared library which implements all > interfaces required by CEPH KeyValueStore. > > > > 2. A new class is derived from KeyValueDB called PropDBStore, > which honors the semantics of KeyvalueStore and KeyValueDB. This class > acts as mediator between CEPH and KVExtension. This class transforms > bufferlist etc... to const char pointers or strings for the extension > to understand. > > > > 3. PropDBStore, loads (dlopen) the KVExtension during OSD > initialization. Path to the KVExtension can be mentioned in > ceph.conf. > > > > 4. Interfaces that needs to be implemented in KVExtension, which > are imported by the PropDBStore are added in a new header called > PropDBWrapper.h. This header contains the signatures for the > necessary interfaces like init(), close(), submit_transaction(), get() > and get_iterator(). Similarly for Iterator functionality, > PropDBIterator.h, which specifies the signatures of seek_to_first (), > seek_to_last(), lower_bound() and upper_bound() etc... PropDBStore > includes these headers to import the symbols, using dlsym(). > > > > 5. Choosing the proprietary DB as Backend to the OSD is > controlled/managed by config options of the ceph (/etc/ceph/ceph.conf) > like rocksdb or leveldb. > > > > 6. Rest of the existing functionality is not disturbed by this > change. Changing the osd backend option will change backend > implementation. But this change is not dynamic. The type of the > backend should be chosen at osd creation time and osd will continue > use that backend till that osd is reformatted again. > > > > 7. The new KVStore we are trying to integrate works on a raw > partition, so we divided the osd drive into two partitions. One > partition is given to osd Meta data (super block, fsid etc...), and > the other is given to the new db to manage it. OSD partition is now > not the entire disk, but 2-4GB which needed for the metadata. > > > > > > This sounds like a good approach to link to pretty much any > external backend (modulo the dlopen part). I need to check with > lawyer types before I can promise we'll be able to merge something > like this into the main ceph.git, though! > > > > > > Thanks- > > > 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). > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe > ceph-devel" > > > in the body of a message to majord...@vger.kernel.org More > majordomo > > > info at http://vger.kernel.org/majordomo-info.html > > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe > ceph-devel" > > in the body of a message to majord...@vger.kernel.org More majordomo > > > info at http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe > ceph-devel" > > in the body of a message to majord...@vger.kernel.org More majordomo > > > info at http://vger.kernel.org/majordomo-info.html > > > > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" > in > the body of a message to majord...@vger.kernel.org More majordomo info > at http://vger.kernel.org/majordomo-info.html -- Matt Benjamin CohortFS, LLC. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://cohortfs.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ________________________________ 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).
