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

luminous: os/bluestore: set bitmap freelist resolution to min_alloc_size #18050

Merged
merged 6 commits into from Oct 13, 2017

Conversation

Projects
None yet
2 participants
@xiexingguo
Member

xiexingguo commented Sep 30, 2017

No description provided.

liewegas added some commits Sep 8, 2017

os/bluestore: require that bluefs_alloc_size be multiple of min_alloc…
…_size

Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 5b47ac5)
os/bluestore: mkfs: choose min_alloc_size earlier
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 3efde01)
os/bluestore/FreelistManager: create: accept min alloc size
Accept a block size other than bdev_block_size.  Let's call it, oh, I don't
know, min_alloc_size.

Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 52453d4)
os/bluestore: align bluefs_extents to min_alloc_size
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 0c777ef)
os/bluestore: use min_alloc_size for freelist resolution
For HDD with min_alloc_size=64k, this is a 16x reduction in allocation
metadata!

Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 6b8e4d5)

Conflicts:
Slightly conflict with 834542c, which
drops the literal description of apply().
@liewegas

This comment has been minimized.

Show comment
Hide comment
@liewegas

liewegas Oct 2, 2017

Member

need to include 4959ad3 too

Member

liewegas commented Oct 2, 2017

need to include 4959ad3 too

@xiexingguo

This comment has been minimized.

Show comment
Hide comment
@xiexingguo

xiexingguo Oct 2, 2017

Member

need to include 4959ad3 too

Added.

Member

xiexingguo commented Oct 2, 2017

need to include 4959ad3 too

Added.

os/bluestore: ignore 0x2000~2000 extent oddity from luminous upgrade
Luminous does a block_size granularity freelist, and assumes that
0~ROUND_UP_TO(SUPER_RESERVED,block_size) is used.  Current master uses
min_alloc_size granularity and changes that assumption to
0~ROUND_UP_TO(SUPER_RESERVED,min_alloc_size).  That means if master
fsck's a luminous-created bluestore, it will think 0x2000~2000 is used
(current baked-in min_alloc_size-based assumption) but the old freelist
says it is free (old mkfs assumption).  The disparity is harmless since
the extent is below min_alloc_size, so ignore it.

Fixes: http://tracker.ceph.com/issues/21408
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 4959ad3)

@liewegas liewegas added the needs-qa label Oct 2, 2017

@liewegas liewegas merged commit d3804d2 into ceph:luminous Oct 13, 2017

3 of 4 checks passed

Docs: build check Docs: failed with errors
Details
Signed-off-by all commits in this PR are signed
Details
Unmodified Submodules submodules for project are unmodified
Details
make check make check succeeded
Details

@xiexingguo xiexingguo deleted the xiexingguo:wip-pr-17610 branch Oct 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment