Follow-up to #286 / PR #288, suggested by @maximthomas in the PR #288 review.
PR #288 makes the MVV read paths tolerate a version whose length field still carries the mark bit (left behind by an interrupted prune on a pre-fix version): visitAllVersions, fetchVersion and fetchVersionByOffset now read lengths via the canonical accessor, which strips the mark bit silently.
That is correct for reads, but it also makes stale marks invisible to IntegrityCheck: IntegrityCheck.visitDataRecord goes through MVV.visitAllVersions, so a page already on disk with a leftover mark now reads clean and icheck reports nothing. The mark survives in the length field until some future prune rewrites that version.
Proposal: have IntegrityCheck count versions where MVV.isMarked(...) is true as a fault (or at least a reported counter), so volumes affected by the pre-#288 corruption can be identified. This likely needs a small extension of MVV.VersionVisitor (or a dedicated scan in visitDataRecord) plus a new counter in the icheck report — which is why it is split out of PR #288 rather than bundled in.
Follow-up to #286 / PR #288, suggested by @maximthomas in the PR #288 review.
PR #288 makes the MVV read paths tolerate a version whose length field still carries the mark bit (left behind by an interrupted prune on a pre-fix version):
visitAllVersions,fetchVersionandfetchVersionByOffsetnow read lengths via the canonical accessor, which strips the mark bit silently.That is correct for reads, but it also makes stale marks invisible to
IntegrityCheck:IntegrityCheck.visitDataRecordgoes throughMVV.visitAllVersions, so a page already on disk with a leftover mark now reads clean andicheckreports nothing. The mark survives in the length field until some future prune rewrites that version.Proposal: have
IntegrityCheckcount versions whereMVV.isMarked(...)is true as a fault (or at least a reported counter), so volumes affected by the pre-#288 corruption can be identified. This likely needs a small extension ofMVV.VersionVisitor(or a dedicated scan invisitDataRecord) plus a new counter in the icheck report — which is why it is split out of PR #288 rather than bundled in.