Summary
Data integrity depends on where a check begins and ends. ECC memory, filesystem checksums, replicated objects, and application digests address different failure paths; none independently proves that bytes were correct before their first checksum. A Btrfs key-order error is a reason to investigate hardware and software, not a diagnosis of faulty RAM. [2–4, 6–9]
Method and collection date
This report synthesizes manufacturer specifications and upstream filesystem, kernel, database, and object-format documentation collected in October 2026. It is a mechanism review, not a hardware test or failure reconstruction. Public link availability was checked in November 2026 with scripted HTTP requests; availability does not establish that a rolling document still matches its earlier content.
Findings
1. ECC is one layer, not an end-to-end guarantee
The Synology DS1821+ datasheet specifies 4 GB of DDR4 ECC SO-DIMM memory, two slots, and a maximum of 32 GB. Synology's memory catalog identifies supported modules and warns about third-party expansion. Match the exact module and applied-model listing rather than assuming that capacity or a similar part number proves compatibility. These are specifications reviewed as of October 2026, not a purchasing recommendation. [1–2]
ECC reduces some memory-error risks but does not protect every CPU, cache, controller, or software path. PostgreSQL's integrity-checking documentation explicitly cautions against treating ECC as absolute protection. Successful booting and a supported module listing do not demonstrate that ECC is operating correctly in a particular installation. [2, 7]
2. A valid checksum does not prove valid application input
Btrfs normally calculates checksums before storage writes and validates them after reads. Its tree checker also examines metadata structure, including key order. Structural failure can point to faulty memory or other hardware corruption, but software defects remain possible. The stage at which an error appears matters: a block rejected before writing is different evidence from a block rejected after reading. [3–5]
Mechanism inference: if bytes become incorrect before their checksum is generated, the stored checksum can faithfully describe the incorrect bytes. If corruption occurs later, detection depends on whether the next check covers that path. An independent known-good reference is needed to distinguish the intended content from a self-consistent damaged copy. [4–5, 13]
Current upstream tree-checker documentation must not be treated as proof of every older vendor kernel's write path. Implementation-specific conclusions require matching source and build evidence. [3]
3. Protection boundaries differ
| Layer | What it checks or provides | What it does not establish |
|---|---|---|
| Btrfs checksums and scrub | Stored checksummed data and metadata; repair where a suitable redundant copy exists | Correct input before checksum creation, or checksum coverage for every file [4–5] |
| PostgreSQL page checksums | Database page integrity at the documented page boundary | Correctness of every in-memory value or query result [6–7] |
| OCI content descriptors | Content identity through a digest and size | Whether the original build or uploaded content was intended [8] |
| Object-store erasure coding | Reconstruction from available data and parity shards | An independent original when all shards were formed from already incorrect input [9] |
| rsync transfer verification | Consistency across its transfer checks | Recovery of intended bytes already wrong on the sender [10] |
The last column distinguishes mechanism limits from product failures: storing or transferring a self-consistent object is not itself evidence that a particular product malfunctioned.
flowchart TD
I["Application input: not proven correct by a later checksum"] --> M["Memory: ECC reduces some memory-error risks only"]
M --> W["Btrfs checksum creation before writes"]
W --> S["Stored checksummed data and metadata"]
S --> R["Btrfs checksum validation after reads"]
R --> A["Application boundaries: page integrity or content digest and size"]
S --> T["Replication / transfer: reconstruction or transfer consistency"]
T --> C["A self-consistent copy is not an independent original"]
N["NOCOW file data: no Btrfs data checksums"] -.-> R
4. NOCOW and cache settings change what a clean result means
Btrfs documents that NOCOW file data lacks data checksums, while metadata remains protected. Scrub cannot use missing file-data checksums to select a correct copy. A VM disk image therefore needs its actual file flags checked; its filename or extension does not establish checksum coverage. Guest and application checks remain necessary where host data checksums are absent. [5]
Direct I/O is also not synonymous with durable completion. Linux documents O_DIRECT as an I/O-path option and distinguishes it from the guarantees of synchronous I/O. Bypassing one cache does not establish that every downstream cache has persisted a write. [11]
5. Verification should combine independent checks
A practical verification plan separates memory diagnostics, filesystem checks, content comparison, and application validation. Synology documents a memory-test procedure; PostgreSQL documents page and structural checks; OCI descriptors provide a content-identity boundary. No one result substitutes for all the others. [6–8, 12]
The transferable recommendation is to retain an independent recovery copy and compare important restored content against a reference created outside the suspected failure path. This is a risk-control recommendation derived from the protection boundaries above, not a claim that a recovery or test has been performed.
Limitations
No device, memory module, cache, filesystem, or application was inspected for this report. No failure probability, defective component, successful repair, or universal scrub interval is established. Product specifications and rolling documentation reflect the October 2026 review and may change. HTTP success verifies a link response, not the completeness of its contents. Personal incident particulars and retailer prices are excluded.
References
- Synology, DS1821+ datasheet: https://global.download.synology.com/download/Document/Hardware/DataSheet/DiskStation/21-year/DS1821%2B/enu/Synology_DS1821%2B_Data_Sheet_enu.pdf
- Synology, DDR4 memory catalog: https://www.synology.com/en-global/products/DDR4
- Btrfs, Tree checker: https://btrfs.readthedocs.io/en/latest/Tree-checker.html
- Btrfs, Checksumming: https://btrfs.readthedocs.io/en/stable/Checksumming.html
- Btrfs, Scrub: https://btrfs.readthedocs.io/en/stable/Scrub.html
- PostgreSQL 18, Data checksums: https://www.postgresql.org/docs/18/checksums.html
- PostgreSQL 18, amcheck: https://www.postgresql.org/docs/18/amcheck.html
- OCI Image Specification, Content descriptors: https://github.com/opencontainers/image-spec/blob/main/descriptor.md
- MinIO, Erasure coding: https://github.com/minio/minio/blob/master/docs/erasure/README.md
- rsync manual: https://download.samba.org/pub/rsync/rsync.1
- Linux man-pages, open(2): https://man7.org/linux/man-pages/man2/open.2.html
- Synology, Memory-test procedure: https://kb.synology.com/en-sg/DSM/tutorial/How_can_I_run_a_memory_test_on_my_Synology_NAS
- Linux kernel, Data integrity: https://origin.kernel.org/doc/html/latest/block/data-integrity.html