From dbc2225315339a52e542c2f78575ee5d1305c2d0 Mon Sep 17 00:00:00 2001 From: Matthew Jackson <1085847+MattJackson@users.noreply.github.com> Date: Wed, 24 Jun 2026 01:51:21 -0700 Subject: [PATCH] =?UTF-8?q?fix:=20correct=20Profile-07=20comment=20?= =?UTF-8?q?=E2=80=94=20prime=5Fcache(lba)=20reads=20lba-3..lba-1,=20not=20?= =?UTF-8?q?lba=20itself?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- tests/passn_handler_ab.rs | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/tests/passn_handler_ab.rs b/tests/passn_handler_ab.rs index 6518fa4..79eee81 100644 --- a/tests/passn_handler_ab.rs +++ b/tests/passn_handler_ab.rs @@ -688,14 +688,15 @@ fn profile_07_medium_then_good() { trace, ); - // GOLDEN: patch's cache-priming (`prime_cache`) issues 3 - // throwaway single-sector reads at lba-3..lba before each count==1 - // recovery read. Those throwaway reads ADVANCE the per-LBA script - // step counter even though their results are discarded. So a - // 3-step script (fail, fail, ok) gets consumed by 2 prime calls - // plus 1 real read → the real read sees `Ok` and the sector is - // recovered. Net effect: patch fully recovers the range in one - // pass thanks to priming, even though the script said "fails on + // GOLDEN: patch's cache-priming (`prime_cache`) issues 3 throwaway + // single-sector reads at lba-3, lba-2, lba-1 (NOT lba itself) before + // each count==1 recovery read. In the default REVERSE patch pass, + // lba 108's prime reads lba 105 (consuming step 0 = fail) and lba 107's + // prime reads lba 105 again (consuming step 1 = fail), so when the real + // recovery read for lba 105 occurs its script step is 2 (= ok). + // prime_cache(105) itself reads 102, 103, 104 — it does NOT advance + // lba 105's own counter. Net effect: patch fully recovers the range in + // one pass thanks to priming, even though the script said "fails on // first two attempts." // // This is the documented cache-prime behavior (`disc/patch.rs`