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

os/bluestore: compensate for bad freelistmanager size/blocks metadata #17268

Merged
merged 1 commit into from Aug 27, 2017

Conversation

liewegas
Copy link
Member

This repairs bluestores created before http://tracker.ceph.com/issues/21089
was fixed in f6f1ae3.

In both cases, the freelistmanager's size is off by one block (4k). In
one case, it is just a matter of fixing the size and twiddling the trailing
bit. In the second case, the size delta causes freelistmanager to need
a new row, which means the blocks count also changes, and we have lots
of bits to zero (all but one in the new row).

Both are silently corrected by fsck in this patch.

Fixes: http://tracker.ceph.com/issues/21089
Signed-off-by: Sage Weil sage@redhat.com

This repairs bluestores created before http://tracker.ceph.com/issues/21089
was fixed in f6f1ae3.

In both cases, the freelistmanager's size is off by one block (4k).  In
one case, it is just a matter of fixing the size and twiddling the trailing
bit.  In the second case, the size delta causes freelistmanager to need
a new row, which means the blocks count also changes, and we have lots
of bits to zero (all but one in the new row).

Both are silently corrected by fsck in this patch.

Fixes: http://tracker.ceph.com/issues/21089
Signed-off-by: Sage Weil <sage@redhat.com>
Copy link
Member

@xiexingguo xiexingguo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Brilliant!

@xiexingguo xiexingguo merged commit dbe1e6e into ceph:master Aug 27, 2017
@xiexingguo
Copy link
Member

backport: #17273

@liewegas liewegas deleted the wip-21089 branch August 27, 2017 02:01
@liewegas
Copy link
Member Author

I think we should actually revert the commit in master, since all upgrades will pass through luminous and the issue will get corrected there.

@xiexingguo
Copy link
Member

I think we should actually revert the commit in master, since all upgrades will pass through luminous and the issue will get corrected there.

yeah, #17275

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants