This bug was initially created as a copy of Bug #2003207
I am copying this bug because:
We want to backport the fix to the RHCS 4.x release.
Description of problem:
[Bluestore] Remove the possibility of replay log and file inconsistency
https://tracker.ceph.com/issues/50965
In power-off conditions, BlueFS can create corrupted files.
It is possible to create a condition in which a BlueFS contains a file that is corrupted. It can happen when the BlueFS replay log is on device A and we just wrote to device B.
Scenario:
1) write to file h1 on a SLOW device
2) flush h1 (and trigger h1 mark to be added to bluefs replay log, but no fdatasync yet)
3) write to file h2 on DB
4) fsync h2 (forces replay log to be written, after fdatasync to DB)
5) power off
As a result, we have file h1 that is properly declared in the replay log but with uninitialized content.
Version-Release number of selected component (if applicable):
RHCS 4.x, 5.x
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Moderate: Red Hat Ceph Storage 4.3 Security and Bug Fix update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2022:1716