From e803905265781ec5b8260b50c3171f98a9a3524d Mon Sep 17 00:00:00 2001
From: Matthew Jackson <1085847+MattJackson@users.noreply.github.com>
Date: Tue, 30 Jun 2026 21:12:12 -0700
Subject: [PATCH] section_recover: Jump starts at 8 MiB base to clear big dead
 spots faster

Each dead probe read costs the drive's full ~10s timeout, so a large dead
region took a dozen escalating probes. Starting the jump at 8 MiB (vs
1 MiB) clears it in a handful; a skipped span stays bad for Bisect to
reclaim readable islands, so an over-jump loses nothing.
---
 src/disc/section_recover.rs | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/disc/section_recover.rs b/src/disc/section_recover.rs
index 7d75542..3674e43 100644
--- a/src/disc/section_recover.rs
+++ b/src/disc/section_recover.rs
@@ -46,8 +46,11 @@ const BATCH_SECTORS: u64 = 32;
 /// find where readable data resumes rather than reading every dead sector.
 const JUMP_AFTER_FAILS: u32 = 2;
 /// `Jump` initial skip distance; doubles after each jump, capped at
-/// [`JUMP_CAP_BYTES`]. Mirrors the escalating Pass-1 damage-jump.
-const JUMP_BASE_BYTES: u64 = 1 << 20; // 1 MiB
+/// [`JUMP_CAP_BYTES`]. Starts large so a big dead region is cleared in a handful
+/// of ~10 s probe reads instead of a dozen (each dead read costs the drive's
+/// full timeout). A skipped span is left bad for Bisect to reclaim any readable
+/// islands, so an over-jump loses nothing — it just defers precision.
+const JUMP_BASE_BYTES: u64 = 8 << 20; // 8 MiB
 const JUMP_CAP_BYTES: u64 = 256 << 20; // 256 MiB
 
 /// Where a handler left the section after its bounded attempt.