From 9d6974df3e5b8bd1da52431894a02051a199a6eb Mon Sep 17 00:00:00 2001
From: MattJackson <1085847+MattJackson@users.noreply.github.com>
Date: Sun, 17 May 2026 09:49:03 -0700
Subject: [PATCH] iter13 base: lock chunk back to 32 MiB after iter12 revert

iter12 revert restored chunk to 128 (iter11 value) by way of the
revert chain. Setting it back explicitly to 32 for iter13. We're
back to iter8 baseline config (no Phase 2.5, 32 MiB chunks,
DONTNEED, no app-level FileSectorSource buffer, channel depth 32).

iter13 is instrumentation: strace the mux thread during a known-dip
to see where time is actually going.
---
 src/io/writeback_file/mod.rs | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/src/io/writeback_file/mod.rs b/src/io/writeback_file/mod.rs
index 0995c98..f9b226f 100644
--- a/src/io/writeback_file/mod.rs
+++ b/src/io/writeback_file/mod.rs
@@ -73,13 +73,10 @@ use std::path::Path;
 use super::writeback::WritebackPipeline;
 
 /// Granularity at which the Linux writeback pipeline issues
-/// `sync_file_range` pairs.
-///
-/// iter11 (2026-05-17): 32 → 128 MiB. 0.21.14 tried this under Phase
-/// 2.5 and reverted; with Phase 2.5 disabled (iter8 baseline) the
-/// tradeoff is different. iter8 (32 MiB) = 28.7, iter9 (64 MiB) = 27.5.
-/// Trying 128 to see if the iter9 dip was noise or a real trend.
-const WRITEBACK_CHUNK_BYTES: u64 = 128 * 1024 * 1024;
+/// `sync_file_range` pairs. 32 MiB is the empirically best value:
+/// iter8 = 28.7, iter9 (64 MiB) = 27.5, iter11 (128 MiB) = 16.6,
+/// iter6 (8 MiB) = 15.8. Locked.
+const WRITEBACK_CHUNK_BYTES: u64 = 32 * 1024 * 1024;
 
 pub(crate) struct WritebackFile {
     file: File,