Checkpoint (CHKP)#

The Checkpoint is the atomic commit point of a ReFS volume. A volume keeps two alternating checkpoints; each is one metadata page — 4 consecutive clusters on 4K-cluster volumes (16 KiB page) or 1 cluster on 64K-cluster volumes (64 KiB page). The copy with the higher virtual clock is the current one, and the lower-clock copy is the previous consistent state (a rollback target until the next flush).

Field Layout#

Checkpoint selection and fallback#

Each CHKP carries a self-checksum verified at mount — the algorithm is cluster-size-dependent (4-byte CRC32-C on 4K-cluster, 8-byte CRC64 on 64K-cluster, 32-byte SHA-256 on SHA-256 volumes), the same mechanism the Superblock uses. At mount, ChooseCheckpointRecord picks the copy with the highest virtual clock among the copies that pass their checksum. An invalid higher-clock copy is skipped, falling back automatically to the lower-clock valid copy; if both fail, the mount fails. Because each flush writes the other slot with clock+1, the lower-clock slot always holds the previous consistent state.

CHKP Flags (offset 0x78)#

Composite Flag Values by Version#

The 0x0080 bit cleanly separates native-formatted v3.10+ volumes (set) from upgraded-from-v3.4 volumes (clear) — an independent corroboration of the volume information driver-version-stamp upgrade signal.

Direct vs Indirect Root Access#

The 13 root table pointers have two encodings, selected by flag bit 0x0200:

• Without 0x0200 (direct): 13 page references stored inline starting at CHKP+0x94
• With 0x0200 (indirect): CHKP+0x94 holds a u32 offset within the same checkpoint page to the root-list region (not a pointer to a separate page — the value is far smaller than one page and equals the embedded-data base offset)

Critical: A parser must read the flag bit before decoding the root list. Reading an indirect-mode checkpoint as direct (or vice versa) yields 13 wrong root addresses.

13 Root Table Pointers#

Roots 7, 8, and 12 use real (physical) LCNs as a bootstrap exception; every other root uses virtual addressing (VLCN → PLCN via the Container Table).

Failover pairs: 0/5 (Object ID), 3/9 (Schema), 7/8 (Container). Block Refcount (#6) has no failover pair.

The Container-Table failover pair (roots 7 & 8) is the set {0x0B, 0x0C} at roots {7, 8} — the common ordering is root 7 = 0x0B / root 8 = 0x0C, but the two can appear swapped, so the invariant is the set, not a fixed index→Table-ID order.

Version Echo (offset 0x50)#

The version echo distinguishes natively formatted v3.10+ volumes from upgraded ones.

Virtual Clock Typical Values#

Parsing Sequence#

1. Read 80-byte page header; verify signature is "CHKP"
2. Read version at 0x54/0x56
3. Read page reference size at 0x5C (determines stride for root list traversal)
4. Read CHKP flags at 0x78
5. Check bit 0x0200 to determine direct vs indirect root mode
6. Parse the 13 root pointers accordingly at 0x94
7. For each root, use the appropriate addressing mode (virtual for most, physical for roots 7, 8, 12)

Cross-references#

• Superblock (SUPB) – the SUPB stores pointers to the two CHKP locations
• Page References – the page reference size at CHKP+0x5C selects the format
• Object Table – root 0 (and failover root 5)
• Container Table – root 7 (and failover root 8)
• Container Index – root 10
• Allocators – roots 1, 2, 12
• Schema Table – root 3 (and failover root 9)

Evidence#

The page header signature, the 13 root-table identities, the version fields, and the page-reference sizes are confirmed in the decompiled driver and the binary string literals; ValidateCheckpointRecord checks the flag bits at CHKP+0x78 and ChooseCheckpointRecord performs highest-clock selection. The flag composites, the version echo, the real-LCN bootstrap exception for roots 7/8/12, and the field offsets were re-measured directly on disk across the corpus. The 0x88/0x8C populated-vs-zeroed co-variation is confirmed. The CHKP flag decomposition is confirmed.