Actions
Bug #56533
closedBluefs might put an orpan op_update record in the log
% Done:
0%
Source:
Tags:
backport_processed
Backport:
quincy, pacific
Regression:
No
Severity:
3 - minor
Reviewed:
Description
This has been originally revealed in Octopus when recycle_log_file_num is set to 0. See https://tracker.ceph.com/issues/55636
In that case RocksDB might issue a weird op sequence on WAL file:
- h = open_for_write(f)
..
- add some data
...
- unlink(f)
- flush(h)
- close(h)
...
As a result relevant file has got op_update record following op_unlink one in BlueFS log.
Which causes either false positive in allocations' check during log replay or file link counting check's failure on replay completion.
Updated by Igor Fedotov almost 2 years ago
- Status changed from New to In Progress
- Assignee set to Igor Fedotov
- Backport set to quincy, pacific, octopus
Updated by Igor Fedotov almost 2 years ago
- Related to Bug #55636: octopus: osd-bluefs-volume-ops.sh: TEST_bluestore2 fails with "FAILED ceph_assert(r == 0)" added
Updated by Igor Fedotov almost 2 years ago
- Status changed from In Progress to Fix Under Review
- Pull request ID set to 47065
Updated by Igor Fedotov over 1 year ago
- Status changed from Fix Under Review to Pending Backport
Updated by Igor Fedotov over 1 year ago
- Backport changed from quincy, pacific, octopus to quincy, pacific
Updated by Backport Bot over 1 year ago
- Copied to Backport #57027: pacific: Bluefs might put an orpan op_update record in the log added
Updated by Backport Bot over 1 year ago
- Copied to Backport #57028: quincy: Bluefs might put an orpan op_update record in the log added
Updated by Igor Fedotov 9 months ago
- Status changed from Pending Backport to Resolved
Actions