From 3919ae19dc6be32582e6eea26a25488ba5b9ff12 Mon Sep 17 00:00:00 2001 From: Tim Serong Date: Tue, 17 Oct 2023 21:32:38 +1100 Subject: [PATCH] rgw/sfs: testing: TestSFSWALCheckpoint: drop explosion test to 300MB Since adding storage_pool, the WAL doesn't explode quite as much as it used to with 10 threads and 1000 objects each (previously with multiple unpooled connections it'd reliably go over 500MB, but I've just seen a unit test where it "only" got to ~450MB, so let's drop the value we test against a bit such that we still confirm the problem, but have more wiggle room). Signed-off-by: Tim Serong --- src/test/rgw/sfs/test_rgw_sfs_wal_checkpoint.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/test/rgw/sfs/test_rgw_sfs_wal_checkpoint.cc b/src/test/rgw/sfs/test_rgw_sfs_wal_checkpoint.cc index c6e98109b6e9e3..aefe4b1aed97cd 100644 --- a/src/test/rgw/sfs/test_rgw_sfs_wal_checkpoint.cc +++ b/src/test/rgw/sfs/test_rgw_sfs_wal_checkpoint.cc @@ -114,9 +114,9 @@ TEST_F(TestSFSWALCheckpoint, confirm_wal_explosion) { // Using the SQLite default checkpointing mechanism with // 10 concurrent writer threads will easily push us past - // 500MB quite quickly. + // a few hundred megabytes quite quickly. std::uintmax_t max_wal_size = multithread_object_create(10, 1000); - EXPECT_GT(max_wal_size, SIZE_1MB * 500); + EXPECT_GT(max_wal_size, SIZE_1MB * 300); // The fact that we have no size limit set means the WAL // won't be truncated even when the last writer completes,