The detection half is solid — countMarkedVersions terminates safely (getLength() masks to 0x7FFF, so from advances by at least LENGTH_PER_VERSION), the dedicated scan is the right call over extending VersionVisitor, and MVVTest (40/40) + IntegrityCheckTest (10/10) are green on the branch.

The problem is the remediation the PR prescribes. Requesting changes on that.

icheck -p remediation silently resurrects deleted keys (high)

The PR says "icheck -p remains the remediation path … marks are reported first and then rewritten by the prune." That is not safe: MVV.prune uses the same bit as its private "keep this version" flag and never clears pre-existing marks before pass 1. A leftover mark is therefore read as prune's own decision to keep:

• persistit/core/src/main/java/com/persistit/MVV.java:530-546 — the primordial branch promotes the first marked version it finds. With a stale mark on an older version, the obsolete version wins. Note the branch is still entered: marked counts only prune's own mark() calls (1), while two versions actually carry the bit.
• persistit/core/src/main/java/com/persistit/MVV.java:508-524 — pass 2 registers only !isMarked versions in prunedVersionList. The marked version that pass 3 doesn't promote is therefore discarded without ever being registered, so its long-record page (lines 515-520) is never deallocated. Observed: prunedVersionList is empty in the stale-mark run vs. one entry in the control.

Reproduced on this branch at unit level (two committed versions, mark on the older one, MVV.prune called directly):

leftoverMark=false  survivor=[22 22]     prunedVersionList.size=1   <- correct, newest version
leftoverMark=true   survivor=[11 11 11]  prunedVersionList.size=0   <- stale version promoted

And end-to-end through the exact path the PR recommends — testPruneClearsLeftoverMarkBits plus a before/after snapshot of the visible key set, with a control run that calls corrupt5's ex.store() but skips MVV.mark:

>>> doMark=false  markedVersions=0   faults=0   keysBefore=500  keysAfter=500
>>> doMark=true   markedVersions=10  faults=10  keysBefore=500  keysAfter=505

icheck -p undeleted 5 transactionally removed keys. The mark sat on the value version, so prune promoted it instead of the AntiValue. The control rules out corrupt5's non-transactional store as the cause.

The bug lives in MVV.prune and predates this PR, but this PR is what tells operators to run icheck -p on affected volumes, and testPruneClearsLeftoverMarkBits asserts remediation "works" while only checking counters. Suggested:

1. Make prune defensive about its own invariant — clear any pre-existing marks before pass 1 (you already have the scan):

// MVV.prune, before the first pass
if (countMarkedVersions(bytes, offset, length) > 0) {
    int from = offset + 1;
    while (from + LENGTH_PER_VERSION <= offset + length) {
        final int vlength = getLength(bytes, from);
        unmark(bytes, from);
        from += vlength + LENGTH_PER_VERSION;
    }
}

2. Add the data-preservation assertion to testPruneClearsLeftoverMarkBits in
   persistit/core/src/test/java/com/persistit/IntegrityCheckTest.java:132 — snapshot the visible key/value set before corruption, compare after remediation. That single assertion is what surfaces this.

icheck -P (pruneAndClear) regresses on affected volumes (medium)

_faults is never cleared (reset() at persistit/core/src/main/java/com/persistit/IntegrityCheck.java:786 doesn't touch it), and the new fault is added during buffer.verify — i.e. before the prune in the same verifyPage call. So the gate at persistit/core/src/main/java/com/persistit/IntegrityCheck.java:315 can never pass on an affected volume: resetMVVCounts is skipped even though the prune fully rewrote the marks.

Confirmed by running the real runTask() path (icheck trees=* -u -P -v), against a control that stores the same records without setting the mark bit:

>>> doMark=false  marked=0   faults=0   -> "0 aborted transactions were cleared by pruning"
>>> doMark=true   marked=10  faults=10  -> "PruneAndClear failed to remove all aborted MMVs"

Before this PR the same volume ran -P to completion.

Options: keep marked-version faults in a separate list excluded from the -P gate; re-verify after pruning and drop the fault when the count reaches zero; or at minimum document "run icheck -P twice".

Marked-version count runs on an unvalidated MVV (low)

persistit/core/src/main/java/com/persistit/IntegrityCheck.java:206 calls countMarkedVersions before visitAllVersions validates the record, so a structurally corrupt MVV is walked with garbage lengths. Confirmed — an MVV with only a damaged length field and no mark bit anywhere:

intact  -> marked=0
corrupt -> marked=1

That yields a bogus MVV has 1 version with a leftover mark bit fault and an inflated MarkedVersions counter next to the genuine CorruptValueException fault — misleading exactly when an operator is using the counter to answer "am I affected by #286?". The inline comment says the count "must be counted before visitAllVersions", but there is no such constraint — visitAllVersions does not mutate bytes. Counting after a clean traversal (or sharing one traversal) fixes it.

Nits

• Doc drift: persistit/doc/Management.rst:136 documents the icheck -c CSV header verbatim and isn't updated with MarkedVersions. Worth noting in the PR description that both the CSV columns and the plain-report format changed — breaking for anything parsing icheck output.
• Redundant page tracking: verifyPage already holds page at persistit/core/src/main/java/com/persistit/IntegrityCheck.java:1187; a field set there would remove the visitPage override and the duplicated _currentPage state.
• Copyright header: MVV.java and MVVTest.java carry Portions Copyrighted 2026 3A Systems, LLC; persistit/core/src/test/java/com/persistit/IntegrityCheckTest.java is modified without it (recent commits 3f8c98909, cca1422d7 do add it).
• corrupt5 duplication: it is a byte-for-byte copy of corrupt2 except for the mutation — a shared helper taking the mutation would be cleaner. Both also leak ignoreMVCCFetch(true) if the loop throws (no finally).
• Test granularity: testLeftoverMarkBitsReported marks one version per record, so faults == markedVersionCount by construction. Marking two versions in one record would cover the counter/fault distinction and the plural() branch.
• Line length: persistit/core/src/main/java/com/persistit/IntegrityCheck.java:209 is 121 chars, one over the file's 120-col wrap (cosmetic — no formatter config in the repo).

One issue left.

-P gate can be defeated by fault-list truncation (medium)

// persistit/core/src/main/java/com/persistit/IntegrityCheck.java:319
if (_faults.size() == _markedVersionFaultCount && _counters._mvvPageCount == _counters._prunedPageCount

addFault drops faults past MAX_FAULTS (200) and returns false, so _markedVersionFaultCount only counts recorded ones:

// persistit/core/src/main/java/com/persistit/IntegrityCheck.java:361
final boolean recorded = _faults.size() < MAX_FAULTS;

Once 200 mark faults fill the list, _faults.size() == _markedVersionFaultCount == 200 and every later fault is silently discarded — including genuine structural ones. The equality still holds, so resetMVVCounts clears the TransactionIndex on a volume with real corruption. _faults.isEmpty() could not be fooled this way.

Reproduced with icheck trees=* -u -P on identically built volumes — same corrupted key in both, only the distribution of marks differs:

marks on keys >=2000   markedRecords=999    faults=200  nonMarkRecorded=2  CLEARED=false  FAILED=true
marks on all keys      markedRecords=2999   faults=200  nonMarkRecorded=0  CLEARED=true   FAILED=false

The first row proves the key corruption is real and detectable here (2 non-mark faults recorded, gate correctly refuses). In the second, 200 mark faults fill the list before the traversal reaches that page, the genuine faults are discarded, and -P clears the TransactionIndex.

Suggested fix: count non-mark faults independently of the cap rather than deriving them by subtraction — e.g. a _nonMarkFaultCount incremented in addFault before the recorded check (with the mark-bit call site using a separate path), and gate on it being zero.

Nits

• Sweep-only prune does not dirty the page — Buffer.pruneMvvValues sets changed only when newSize != oldSize (persistit/core/src/main/java/com/persistit/Buffer.java:3699) and dirties only when changed (Buffer.java:3625). Clearing a stale mark never changes the size, so if prune keeps exactly the versions already present the repair stays in the page image only. Verified at the unit level (pruneMvvValues changed = false while the mark count went 1 → 0), but I could not construct an end-to-end case where a repair is actually lost — reaching it needs a concurrent transaction pinning every version of an already-marked page, and the quiesced path demonstrably persists. Worth a comment at most; mentioning it because it is the one way the -P rationale at IntegrityCheck.java:311-318 could be untrue.
• _prunedPageCount counts no-op prunes — persistit/core/src/main/java/com/persistit/IntegrityCheck.java:1204-1205 ignores pruneMvvValues's return value and increments unconditionally, so the _mvvPageCount == _prunedPageCount half of the gate reduces to "prune did not throw". Pre-existing, but it is load-bearing for the gate this PR changes.
• _markedVersionFaultCount not cleared in reset() — persistit/core/src/main/java/com/persistit/IntegrityCheck.java:792. Consistent with _faults, so only a latent hazard for reused instances.

See
#291 (review) comment