luminous: os/bluestore: Added rescue procedure for bluefs log replay#35776
luminous: os/bluestore: Added rescue procedure for bluefs log replay#35776neha-ojha merged 3 commits intoceph:luminousfrom
Conversation
f722ef8 to
c6674ed
Compare
|
@aclamk - we do want the same in master, don't we? |
|
@aclamk - this might look like a grumbling but IMO that's a bad procedure that is bringing a mess into commit history... May be try pushing hard the patch forward through the master first? |
|
@ifed01 Problem is, that master does not need it. I would be unable to recreate state that is begin fixed here on master. |
you could add an explanation in your commit message to explain why this commit is not cherry-picked from master |
67cae05 to
564c246
Compare
|
@neha-ojha this the one was part of #35776 |
This is a procedure tries to find on disk unreachable extents and pretend they were already a part of bluefs log. If this gives proper crc, accept it. Fixes: https://tracker.ceph.com/issues/46195 Signed-off-by: Adam Kupczyk <akupczyk@redhat.com>
This ability only makes sense as a step that allows to perform fsck before commiting recovered bluefs log. Signed-off-by: Adam Kupczyk <akupczyk@redhat.com>
Adds additional paragraph to ceph-bluestore-tool documentation, describing how to use *special* options --bluefs_replay_recovery and --bluefs_replay_recovery_disable_compact to recover large bluefs log. Signed-off-by: Adam Kupczyk <akupczyk@redhat.com>
a7b7f3e to
cc4c069
Compare
This is a recovery procedure for cases where bluefs log grew so much that it cannot be read.
This fixes https://tracker.ceph.com/issues/46195 .
Recommended procedure:
ceph-bluestore-tool -l /proc/self/fd/1 --log-level 5 --path dev/osd1 fsck --debug_bluefs=5/5 --bluefs_replay_recovery=true --bluefs_replay_recovery_disable_compact=true
Fsck should complete with minimal errors.
ceph-bluestore-tool -l /proc/self/fd/1 --log-level 5 --path dev/osd1 fsck --debug_bluefs=5/5 --bluefs_replay_recovery=true