Interpreting Synology Btrfs errors with vendor source, not mainline assumptions

Summary

Public Synology source narrows the meaning of Btrfs structural errors but does not identify a faulty component. In the inspected DSM base source, quota-tree identifiers, conditional generation checks, local key repair, and retry-buffer hashes all require more careful interpretation than their log messages suggest. Current upstream documentation alone is not enough to characterize an older vendor kernel. [1–5]

Method and collection date

The October 2026 source review examined the public DSM 7.2-64570 V1000 kernel archive and compared selected Btrfs paths with upstream Linux v5.¹ and v5.2. This extends the protection-boundary analysis in NAS data integrity: what ECC, Btrfs, replication, and application checks actually protect by examining a specific public implementation. No vendor source was installed or executed, and no installed binary was matched to the archive. Link availability was checked by scripted HTTP requests in November 2026; the archive was not downloaded again for this draft.

Findings

1. Read validation is ordered, but some checks are conditional

In the inspected fs/btrfs/disk-io.c, btree_readpage_end_io_hook checks the metadata checksum, address, filesystem identity, and level before reaching leaf-structure validation. The expected parent-generation comparison is conditional: a zero expected parent transaction ID bypasses that comparison. A separate parent-generation verification path also accepts the zero-parent case. [1–2]

Consequently, a key-order warning does not by itself prove that every provenance check passed. The relevant call site and its conditions matter. This is a source-level conclusion about the public base archive, not a guarantee about every patched DSM installation. [2]

flowchart TD
    subgraph O["Read-validation order"]
        direction TB
        C["Metadata checksum"] --> A["Address"]
        A --> F["Filesystem identity"]
        F --> L["Level"]
        L --> V["Leaf-structure validation"]
    end
    subgraph G["Conditional parent-generation comparison"]
        direction TB
        P{"Expected parent transaction ID is zero?"} -->|"Yes"| B["Bypass comparison"]
        P -->|"No"| E["Compare expected parent generation"]
    end

2. Final pre-write validation differs across implementations

The inspected Synology write path calls btree_csum_one_bio and csum_dirty_buffer to generate and store the metadata checksum. That path does not contain an unconditional full leaf key-order check immediately before checksum generation. A separate relaxed check is configuration-gated and is not equivalent to unconditional final write validation. [2]

The upstream tagged-source comparison is more precise than a broad statement about “Btrfs”:

Public source	Relevant finding	Interpretation boundary
Synology DSM 7.2-64570 V1000 archive	Inspected final checksum path lacks unconditional full leaf checking	Public base source; installed updates and effective build options were not matched [2]
Upstream Linux v5.1	The inspected checksum path lacks the later full tree validation	A release-tag comparison, not proof about vendor backports [4]
Upstream Linux v5.2	The path calls node or leaf validation before storing the checksum	A temporary checksum is computed earlier; do not describe this as preceding every checksum computation [5]

Current Btrfs documentation describes write-time checking, but that description cannot be projected backward onto a materially different vendor path. The tagged comparison establishes a change between v5.¹ and v5.2; it does not identify an exact introducing commit or prove deployment in DSM. [3–5]

3. Root 208 identifies a vendor tree, not a root cause

The archive's include/uapi/linux/btrfs_tree.h defines BTRFS_SYNO_QUOTA_V2_TREE_OBJECTID as 208. Its lock-class table also names the corresponding tree syno-v2-quota. This supports interpreting that identifier as a Synology quota-v2 tree in the inspected implementation. [2]

It does not establish that quota accounting initiated a fault. A tree can contain the observed damage without being the mechanism that created it. Nor does an upstream quota command become a supported DSM operating procedure merely because the identifier is known.

4. “Fixed” and “same result” are narrower than they sound

The inspected fix_item_key path attempts local key reconstruction using filesystem relationships. A fixed-key warning is not a comparison with an independent known-good original and does not establish durable repair or application correctness. Later repair I/O has its own conditions and possible failures. Repeated messages are therefore not counts of independent physical errors. [2]

In the archive's md RAID1 self-heal path, the message get same result follows equality of consecutive retry-buffer CRC32C values. It is not a byte-for-byte comparison of two complete devices. The message alone does not prove that distinct mirror members were read, that all bytes were identical, or that a shared cache, mapping, power, or software fault has been eliminated. [2]

5. Checksum-consistent malformed metadata has multiple explanations

A malformed block that passes checksum verification is consistent with incorrect content being created before checksum storage. However, software creating invalid content, a mutation between verification and use, stale or misdirected checksum-valid data, checksum collision, and vendor repair behavior remain alternatives. Conditional generation checks further limit what can be inferred from the absence of a generation warning. This is mechanism reasoning from the inspected paths, not a ranking of fault probabilities. [2–3]

Similarly, O_DIRECT must not be used as shorthand for guaranteed durable writes: its documented I/O semantics are distinct from synchronous persistence guarantees. [6]

Limitations

The source review recorded archive SHA-256 9ee1ab5472cd8a50c69c697fa0fc0ae1dffb610b7afd8e75f48b22e2ee1bfaae; this draft preserves that public-artifact identifier but has not independently recomputed it. Line-level conclusions require that exact archive and member bytes. Installed update deltas, configuration, logs, and hardware behavior remain unverified.

No failure rate or component diagnosis is established. Personal exposure intervals and symptom counts were removed rather than converted into general memory-error probabilities. The report does not supply recovery commands or assert that disabling quotas resolves corruption.

References

1. Synology, DSM 7.2-64570 public source index: https://archive.synology.com/download/ToolChain/Synology%20NAS%20GPL%20Source/7.2-64570
2. Synology, V1000 Linux kernel source archive: https://global.synologydownload.com/download/ToolChain/Synology%20NAS%20GPL%20Source/7.2-64570/v1000/linux-4.4.x.txz
3. Btrfs, Tree checker: https://btrfs.readthedocs.io/en/latest/Tree-checker.html
4. Linux v5.1, Btrfs disk-io.c: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/refs/tags/v5.1/fs/btrfs/disk-io.c
5. Linux v5.2, Btrfs disk-io.c: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/refs/tags/v5.2/fs/btrfs/disk-io.c
6. Linux man-pages, open(2): https://man7.org/linux/man-pages/man2/open.2.html