kv: In memory keyvalue db implementation

[chhabaramesh]

In memory key value db implementation with google btree map.
First version with minimal functional implementation.

Signed-off-by: Ramesh Chander Ramesh.Chander@sandisk.com

[chhabaramesh]

@liewegas please review and merge.

[markhpc]

sweeeeet! Thanks Ramesh! Very excited to play with this.

[chhabaramesh]

@markhpc you are welcome. But this is just start, might have to tune it for concurrency.

[chhabaramesh]

@liewegas All tests in ceph_test_objectstore and ceph_test_keyvaluedb passes now. Only problem was the libsnappy issue.

[markhpc]

@chhabaramesh got a chance to test this today. A couple of observations:

1. We need to modify the CMakeLists.txt file otherwise the linker get's angry when trying to build this with cmake. I've done this here: markhpc@5318bb6

2. Pretty quickly I'm hitting segfaults on the OSDs when using this with bluestore. I've included a snippet from gdb:

MemDBStore_Segfault.txt

[chhabaramesh]

@markhpc , Thanks, will look in to it today.

[chhabaramesh]

@markhpc , I fixed the make file issue as suggested.

When do you hit segfault? Can you please tell exact test you are doing?

[markhpc]

@chhabaramesh segfault happened about 0.3s after OSD initialization, but may only be on the first couple of OSDs (at least it is in this test). Looks like the segfaults probably happened during initial default pool creation.

[liewegas]

A good test BTW would be to set the mon_keyvaluedb and filestore_omap_backend to memdb and see if vstart works as expected.

[markhpc]

Did a quick test with mon_keyvaluedb set to memdb which results in:

2016-06-29 11:42:38.494078 7f172b662500 -1 unable to read magic from mon data

No segfaults, mon just doesn't appear to like it. Even with debug 20 there's not much in the mon log to look at.

[chhabaramesh]

@markhpc @liewegas , So far I did

1. ceph_test_objectstore + ceph_test_keyvaluedb
2. Vstart and then single rbd image and fio on top of it

for me it works ok without segfalut.

please let me do more tests , will update you ..

[liewegas]

Can we call it MemDB{.h,.cc}?

[chhabaramesh]

Sure, will change it.

[liewegas]

single /, spaces between operators and operands

[chhabaramesh]

will do that.

[liewegas]

I pushed several patches to https://github.com/liewegas/ceph/commits/wip-mondb.. enough to get the monitor to get most of the way into its startup sequence with 'mon keyvaluedb = memdb'. But it quickly crashes in the iterator code.

[liewegas]

Ah, I disabled the snapshot iterator usage in mon and now it works!

[mattbenjamin]

could shrink critical section (and elsewhere)?

[chhabaramesh]

Yes, I will take utility code out of lock and break code wherever possible. Also, I have in mind overall concurrency improvement for this code using multiple btrees.

[chhabaramesh]

Only thing I can take out of lock is combine strings. Rest needs to be under the lock. For example getting old value and then erasing it needs to be atomic, otherwise erase might fault.

[liewegas]

We need to test and merge #10102 first, then rebase this on top.

[liewegas]

Otherwise this looks good to me!

[tchaikov]

#10102 is merged.

[chhabaramesh]

@markhpc @tchaikov @liewegas rebased and tested. Passes ceph_test_objectstore + ceph_test_keyvaluedb + normal single node osd start and io.
Also did vstart with mondb and bluestore kv = memdb. It comes up and I can do basic read write test.

[markhpc]

Sounds to me like we should merge it!

[chhabaramesh]

@markhpc @tchaikov any update on this?

[mattbenjamin]

Yes, I will take utility code out of lock and break code wherever possible. Also, I have in mind overall > concurrency improvement for this code using multiple btrees.

The TreeX class in cohort_lru.h does something along those lines, but is based on the boost::intrusve tree interface.