From 4369bea1475e82523d6430e055b6a91f24a40ee0 Mon Sep 17 00:00:00 2001 From: Kefu Chai Date: Mon, 1 Jun 2026 13:19:04 +0800 Subject: [PATCH] test/libcephfs: reduce SnapDiffDeletionRecreation bulk_count on Windows this test timed out on Windows. and HugeSnapDiffLargeDelta, at half the file count, passed in 508 seconds on the same run, suggesting this test takes ~17 minutes on Windows -- beyond the test runner limit. we haven't profiled the Windows client yet, but the likely culprit is EventPoll, the Windows messenger backend, which scans the entire poll array on every event_wait() and poll_ctl() call rather than using a keyed data structure. in this change, we reduce bulk_count to 1 << 12 on Windows. the unique thing this test covers is the deletion-recreation pattern: a name that exists as a file in snap1, gets deleted, and reappears as a directory in snap2 -- it must show up in the diff with both snapids. 4096 produces 1024 such pairs, which is enough to exercise that logic. multi-fragment snapdiff is already covered by HugeSnapDiffLargeDelta, which derives its file count from mds_bal_split_size and mds_bal_fragment_fast_factor explicitly to trigger fragmentation. Fixes: https://tracker.ceph.com/issues/77015 Signed-off-by: Kefu Chai --- src/test/libcephfs/snapdiff.cc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/test/libcephfs/snapdiff.cc b/src/test/libcephfs/snapdiff.cc index 18b0aa816d2..fc66a739d34 100644 --- a/src/test/libcephfs/snapdiff.cc +++ b/src/test/libcephfs/snapdiff.cc @@ -2142,7 +2142,12 @@ TEST(LibCephFS, SnapDiffChangedBlockWithCustomObjectSize) } TEST(LibCephFS, SnapDiffDeletionRecreation) { +#ifdef _WIN32 + // Windows client is ~8x slower per file op; 1<<15 exceeds the test timeout + int bulk_count = 1 << 12; +#else int bulk_count = 1 << 15; +#endif TestMount test_mount("/SnapdiffDeletionRecreation"); ASSERT_EQ(0, test_mount.mkdir("bulk")); -- 2.47.3