Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bluestore: do not use freelist to track bluefs_extents #10698

Merged
merged 3 commits into from Aug 18, 2016

Conversation

liewegas
Copy link
Member

We track these explicitly in the bluestore superblock in bluefs_extents--we
dont' need to flip bits. This speeds up mkfs and balancing significantly.

We explicitly track bluefs extents in the bluefs_extents
interval_set stored in the superblock.  Telling the
freelist about it is redundant.  It's also slow, because
bluefs uses a bit portion of the device and the bitmap
representation has to flip a lot of bits in the KV store
during mkfs (or possibly during a freespace balance).

Signed-off-by: Sage Weil <sage@redhat.com>
In init_add_free we only use the min_alloc_size aligned
portion of the provided extent.  Since we have some
callers that add in free space and then take it back,
make init_rm_free do the same.  That way we can, e.g,
init_add_free 0x1000~0x400000000 (alloc will add
0x10000~0x3ffffff0000) and then
init_rm_free 0x1000~0x100000 (alloc will remove
0x10000~0xf0000).

Signed-off-by: Sage Weil <sage@redhat.com>
The only other instance of FreelistManager defines this
differently anyway.

Signed-off-by: Sage Weil <sage@redhat.com>
@liewegas
Copy link
Member Author

retest this please

@liewegas liewegas merged commit a373578 into ceph:master Aug 18, 2016
@liewegas liewegas deleted the wip-bluestore-bluefs-allocation branch August 18, 2016 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant