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 <k.chai@proxmox.com>

diff --git a/src/test/libcephfs/snapdiff.cc b/src/test/libcephfs/snapdiff.cc
index 18b0aa816d231d0ed3691a519674857d88fdcbb5..fc66a739d340a4c748f1b7d191ae96fb067c2aad 100644 (file)
--- 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"));