Bug #50965
closedIn poweroff conditions BlueFS can create corrupted files
0%
Description
It is possible to create condition in which a BlueFS contains file that is corrupted.
It can happen when BlueFS replay log is on device A and we just wrote to device B.
Scenario:
1) write to file h1 on 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) poweroff
In result we have file h1 that is properly declared in replay log, but with uninitialized content.
Updated by Dan van der Ster almost 3 years ago
Why doesn't this need to be backported? The commit applies cleanly to pacific, at least.
Updated by Igor Fedotov almost 3 years ago
- Status changed from Resolved to Pending Backport
- Backport set to pacific, octopus, nautilus
Updated by Backport Bot almost 3 years ago
- Copied to Backport #51128: octopus: In poweroff conditions BlueFS can create corrupted files added
Updated by Backport Bot almost 3 years ago
- Copied to Backport #51129: nautilus: In poweroff conditions BlueFS can create corrupted files added
Updated by Backport Bot almost 3 years ago
- Copied to Backport #51130: pacific: In poweroff conditions BlueFS can create corrupted files added
Updated by Loïc Dachary over 2 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".