From 8919de5b03cf16fe41be0d820d6b45ee3d6f36f3 Mon Sep 17 00:00:00 2001
From: MattJackson <1085847+MattJackson@users.noreply.github.com>
Date: Sun, 17 May 2026 08:39:27 -0700
Subject: [PATCH] iter8: chunk back to 32 MiB on top of Phase-2.5 revert

iter7's 64 MiB chunks didn't help (23.1 vs iter4's 24.0). Reverting
to 32 MiB so iter8 differs from iter4 by exactly one variable:
Phase 2.5 disabled / direct passthrough mux thread.

Test question: is Phase 2.5 helping at all? If iter8 mean > iter4,
Phase 2.5 has been a net negative on this rig the whole time. If
iter8 mean < iter4, Phase 2.5 is doing what it claimed.
---
 src/io/writeback_file/mod.rs | 12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/src/io/writeback_file/mod.rs b/src/io/writeback_file/mod.rs
index db76a06..424d4ff 100644
--- a/src/io/writeback_file/mod.rs
+++ b/src/io/writeback_file/mod.rs
@@ -73,15 +73,9 @@ use std::path::Path;
 use super::writeback::WritebackPipeline;
 
 /// Granularity at which the Linux writeback pipeline issues
-/// `sync_file_range` / `posix_fadvise(DONTNEED)` pairs.
-///
-/// iter7 (2026-05-17): 32 → 64 MiB. iter6 (8 MiB) regressed -8.2 MB/s
-/// vs iter4 (32 MiB), confirming smaller=slower for this workload.
-/// Trying bigger to see if fewer-but-larger syncs reduces overhead
-/// further. 0.21.14 tried 128 MiB and was reverted — we don't know
-/// whether that was measurement noise or a real TCP-buffer / NFS
-/// commit issue. 64 MiB is the middle test point.
-const WRITEBACK_CHUNK_BYTES: u64 = 64 * 1024 * 1024;
+/// `sync_file_range` / `posix_fadvise(DONTNEED)` pairs. 32 MiB
+/// remains the best-tested value.
+const WRITEBACK_CHUNK_BYTES: u64 = 32 * 1024 * 1024;
 
 pub(crate) struct WritebackFile {
     file: File,