Structures
The byte-level on-disk layouts — metadata structure decoded, field by field.
Boot & bootstrap is the fixed chain a parser must walk before anything else: the VBR, superblock, and checkpoint, and the well-known system OIDs they lead to. B+-tree rows & pages is the generic machinery every table is built from — the node header, page and page-reference formats, directory-entry and extent rows, and the reverse index. System tables (the 13 roots) decodes each checkpoint root in turn: the object, schema, parent-child, container, and allocator tables, block reference counts, integrity state, volume info, security, the reparse index, the upcase table, and the trash table. Journals & logs covers the two change records — the USN change journal and the durable MLog transaction log.
Boot & bootstrap
The VBR is a 512-byte structure at sector 0 of the ReFS partition. It provides the format parameters -- cluster size, version, checksum mode -- that every later structure depends on. A backup copy resides in the last…
The Superblock is the fixed-location volume anchor that points to the two alternating checkpoints. It always resides at cluster 30 (LCN 0x1E), occupying a single cluster.
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…
ReFS reserves the OIDs below 0x700 for internal use; user files and directories start at 0x701. These low-numbered objects hold the volume's infrastructure — the upcase table, the log metadata, the security-descriptor…
B+-tree rows & pages
All ReFS metadata is stored in B+-trees with the signature "MSB+". Each node occupies one metadata page: 16 KiB (4 consecutive clusters) on 4 KiB-cluster volumes, or 64 KiB (1 cluster) on 64 KiB-cluster volumes. An MSB+…
Every ReFS metadata page -- SUPB, CHKP, and MSB+ (B+-tree) -- begins with a common 80-byte header. This layout is identical across every version (v3.4 through v3.14 and Insider) and configuration studied. MLog pages use…
A page reference binds a child page's address to a checksum of that child's contents. Every B+-tree parent stores a page reference for each child, chaining the whole metadata tree into a Merkle tree anchored at the…
Directory entries (type 0x30) are B+-tree rows within a per-directory B+-tree. Each file or subdirectory appears as a type 0x30 row in its parent directory's tree. The record placement (embedded vs split) determines the…
Extent descriptors (type 0x40) map a file's logical cluster offsets (VCNs) to virtual LCNs (VLCNs). A VLCN is not a physical address: it must be translated through the Container Table to obtain the physical cluster…
Type 0x20 is the per-object FileId-resolution index: rows keyed by a FileId (object reference / child index) that let the driver, given a file reference, recover either the object's name (Format A) or its home-directory…
System tables (the 13 roots)
The Object Table (roots #0 and #5, schema 0xe030) is the master OID-to-table mapping. Every persistent directory and system object has exactly one entry, so it is the pivot of the namespace. A file has no Object-Table…
The Schema Table (roots #3/#9, schema 0xe060) is self-describing: it contains one entry per table type used by the volume. Each entry fixes the key-comparison rules that let the generic B+-tree engine order rows without…
The Parent-Child Table (root #4, schema 0xe040) encodes the directory hierarchy. It records only directory-to-directory and directory-to-security-mapping relationships; regular files are not tracked. The first row is…
The Container Table (roots #7/#8, schema 0xe0c0) maps virtual container IDs to physical disk locations. It is the second level of ReFS's two-level address translation: per-object extent descriptors map VCN to VLCN, and…
The Container Index (root #10, table ID 0x0E, schema 0xe100) is an alternate index over the Container Table, keyed by allocation state and free space rather than by sequential container ID. It lets the allocator answer…
ReFS tracks free and allocated clusters with a three-tier allocator hierarchy. All three tiers share schema 0xe010 and an identical on-disk row format; they differ only in which region of the volume they manage and how…
The Block Refcount Table (root #6, table ID 0x05, schema 0xe0b0) tracks shared data clusters used by snapshots, deduplication, and clones. The schema and root #6 have existed since v3.4 as an empty B+-tree; the table is…
The Integrity State Table (root #11, table ID 0x0F, schema 0xe080) tracks volume-level integrity-stream coverage. It is present on every volume regardless of whether integrity streams are enabled, and on a quiescent…
The Volume Information table (OID 0x500 primary, OID 0x501 duplicate, schema 0x150) stores the volume label, creation and modify timestamps, version information, and volume flags. It is a small B+-tree whose rows are…
ReFS uses a centralized, content-addressed security model. A SecurityId stored with each file maps directly to OID 0x530, the Security Descriptors table, where the actual SECURITY_DESCRIPTOR structures reside. Identical…
A reparse point is a per-file tag plus payload that redirects path resolution — a symlink, junction, mount point, app-execution alias, or WSL special file. The per-file payload is the $REPARSE_POINT attribute (type…
The Upcase Table (OID 0x07 primary, OID 0x08 duplicate, schema 0xe090) stores the Unicode uppercase mapping that ReFS uses for case-insensitive filename comparison in directory B+-trees. The content is a fixed Windows…
The Trash Table (OID 0x0D, schema 0xe0d0) is an asynchronous deletion queue. When a split-record file or a directory is deleted, the object is reparented into this table for deferred background cleanup rather than being…
Journals & logs
The USN (Update Sequence Number) Journal records every change to files and directories on the volume. ReFS uses the USN_RECORD_V3 format with 128-bit file IDs (NTFS uses the older USN_RECORD_V2 form with a 64-bit file…
The MLog implements write-ahead logging for atomic metadata updates. It is redo-only: on crash recovery, committed transactions are replayed and there is no undo mechanism — copy-on-write keeps prior pages intact, so…