]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
os/bluestore/bluefs: Fix data corruption in truncate() 44860/head
authorAdam Kupczyk <akupczyk@redhat.com>
Tue, 2 Nov 2021 15:57:32 +0000 (16:57 +0100)
committerAdam Kupczyk <akupczyk@redhat.com>
Wed, 2 Feb 2022 13:07:14 +0000 (14:07 +0100)
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 <akupczyk@redhat.com>
(cherry picked from commit 49b7b44b3b5c94ee401562e603999e2b3bd8f9a2)

src/os/bluestore/BlueFS.cc

index f1473d31a78a3b6c5abfbdcbf145dcd7f1a21ee4..1545ed576fdc85975fff7015602d9afc021a1a84 100644 (file)
@@ -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);