bluestore: latest and greatest #6896

liewegas · 2015-12-11T14:38:01Z

rename newstore -> bluestore
use a block device
back rocksdb with BlueRocksEnv, which share block device(s) with bluestore

yuyuyu101 · 2015-12-11T15:11:45Z

COOL, so fast

loic-bot · 2015-12-11T15:21:42Z

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/10087/

FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/10087/

dzafman · 2015-12-11T23:09:59Z

Jenkins:
os/bluestore/bluefs_tool.cc:38:27: error: no matching function for call to 'BlueFS::mount(int, int)'
int r = fs.mount(0, 4096);

dzafman · 2015-12-11T23:10:25Z

Once it builds I'm tempted to modify the test/ceph_objectstore_tool.py to vstart using --bluestore option and test using --type bluestore to see what happens.

loic-bot · 2015-12-12T14:25:45Z

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/10109/

FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/10109/

liewegas · 2015-12-13T00:54:12Z

On Fri, 11 Dec 2015, David Zafman wrote:

Once it builds I'm tempted to modify the test/ceph_objectstore_tool.py to vstart using --bluestore option and test using --type bluestore to see
what happens.

That'd be great!

dzafman · 2015-12-14T21:05:32Z

4 problems found:
keyvaluestore_rocksdb_options as empty string is not handled maybe because RocksDBStore::ParseOptionsFromString() never calls rocksdb::GetOptionsFromString() in that case. I set to "write_buffer_size=1024,max_write_buffer_number=2" as a work around.

Code to handle bluestore_bluefs_env_mirror won't link so I just disabled it because config is false by default anyway.

_open_bdev can't delete bdev without first calling bdev->close();

Bluestore disklabel is overwritten after --mkfs is used to create it, so OSDs just crash with bad decode on start-up with vstart. I saw the the dev/osd0/block had the disklabel after it was written, but when I let the mkfs complete and checked again.

dzafman · 2015-12-14T21:34:12Z

See changes in dzafman@a99dbfd

dzafman · 2015-12-14T21:55:09Z

The empty keyvaluestore_rocksdb_options isn't an issue. It might be related to either the rocksdb build in my tree at one point, or misidentified the cause of a mount failure.

loic-bot · 2015-12-14T22:08:33Z

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/10162/

FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/10162/

loic-bot · 2015-12-14T22:22:28Z

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/10163/

FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/10163/

loic-bot · 2015-12-17T15:29:20Z

FAILURE: http://jenkins.ceph.dachary.org/job/ceph/10272/

FAILURE http://jenkins.ceph.dachary.org/job/ceph/LABELS=centos-7&&x86_64/10272/

dzafman · 2015-12-19T03:18:34Z

I was able to use vstart.sh after making _check_or_set_bdev_label() alway return success instead of even calling _read_bdev_label() which fails.

The test/ceph_objectstore_tools.py test unfortunately relies on looking at the filestore format. So instead of trying to rewrite that test, I created some objects and ran a good portion of the commands with ceph-objectstore-tool and using --type bluestore. I saw no failures. Maybe we should have a generic non-filestore ceph-objectstore-tool test which can supplement the current test. It could then also be used for keyvaluestore or any future objectstores.

The write process may do a read/modify/write on a stripe. In order to allow multiple writes to coexist within the same transaction, we need to be able to "see" our writes. Clear the "cached" stripe values when the last TransContext touching an onode is finished. In theory we could pin memory with a constant stream of updates to an object; we may need to address that later. Signed-off-by: Sage Weil <sage@redhat.com>