From 9036b15b8ee4987bd51a3556ac37a10aaa58da91 Mon Sep 17 00:00:00 2001 From: Adam Kupczyk Date: Tue, 2 Nov 2021 16:57:32 +0100 Subject: [PATCH] os/bluestore/bluefs: Fix data corruption in truncate() 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 and truncated file. Scenario: 1) write to file h1 on SLOW device 2) flush h1 (initiate transfer, but no fdatasync yet) 3) truncate h1 4) write to file h2 on DB 5) fsync h2 (forces replay log to be written, after fdatasync to DB) 6) poweroff Fixes: https://tracker.ceph.com/issues/53129 Signed-off-by: Adam Kupczyk (cherry picked from commit 49b7b44b3b5c94ee401562e603999e2b3bd8f9a2) --- src/os/bluestore/BlueFS.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/src/os/bluestore/BlueFS.cc b/src/os/bluestore/BlueFS.cc index f1473d31a78a3..1545ed576fdc8 100644 --- a/src/os/bluestore/BlueFS.cc +++ b/src/os/bluestore/BlueFS.cc @@ -3150,6 +3150,7 @@ int BlueFS::_truncate(FileWriter *h, uint64_t offset) ceph_abort_msg("truncate up not supported"); } ceph_assert(h->file->fnode.size >= offset); + _flush_bdev_safely(h); vselector->sub_usage(h->file->vselector_hint, h->file->fnode.size); h->file->fnode.size = offset; vselector->add_usage(h->file->vselector_hint, h->file->fnode.size); -- 2.39.5