--- title: "Which Pending Writes Does the Persistent-Memory Power-Failure Domain Cover?" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/persistent-memory-adr-eadr-power-failure-domain" last-updated: "2026-10-21" --- # Which Pending Writes Does the Persistent-Memory Power-Failure Domain Cover? Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. A persistence domain identifies locations from which a documented platform mechanism preserves writes to persistent memory under specified failure conditions. Historical ADR protects memory-controller pending writes; eADR extends the boundary to processor caches with the required platform support. Establish the required bytes' destination and location before counting them as covered. Installation of persistent memory or progress through CPU stores alone does not establish a recoverable application checkpoint. ## ADR protects a pending-write location before the media Intel's third-generation Xeon Scalable overview, ID 660365, updated March 21, 2021, describes Asynchronous DRAM Refresh (ADR) as protecting writes that have reached the memory controller's write-pending queue. The failure response moves those queued writes into persistent memory. Its ADR description excludes processor caches. This explains why persistent and already in the media are different statements. A protected queue can hold pending bytes that the documented response will carry to persistent media. The useful boundary is therefore the protected data path, rather than the media alone. References: [PM1](https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html), [PM3](https://pmem.io/pmdk/manpages/linux/v2.0/libpmem/pmem_flush.3/) ## eADR extends the boundary to processor caches Enhanced ADR (eADR) adds processor-cache protection in Intel's historical description and requires OEM-provided stored energy. The extension protects a path for persistent-memory writes; it does not make the cache circuitry nonvolatile. The practical difference concerns bytes still in caches when the covered failure occurs. A cache-held update excluded by ADR can fall within an applicable eADR claim. Whether that claim applies to the actual server depends on its documented platform implementation and conditions, including the required energy support. A CPU family name alone leaves that relationship unresolved. References: [PM1](https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html), [PM3](https://pmem.io/pmdk/manpages/linux/v2.0/libpmem/pmem_flush.3/) ## The write must target memory exposed for persistence The presence of persistent-memory hardware does not identify how the application uses it. Intel's Optane overview distinguishes Memory Mode, which offers volatile memory capacity, from App Direct Mode, which offers a byte-addressable persistent-memory pool. Those named operating modes explain why an equipment inventory cannot stand in for a description of the application's persistent destination. The PMDK 2.0 mapping reference likewise distinguishes an actual persistent-memory mapping from a mapped file that requires a different persistence mechanism. The address range and its backing matter alongside the installed components. For the comparison here, only writes targeting an appropriately exposed persistent-memory range enter the domain assessment. Ordinary DRAM, CPU registers, GPU HBM and unrelated software state are not added to the protected checkpoint population by the ADR or eADR label. A file mapping also needs its own backing identified before the direct persistent-memory explanation is applied to it. References: [PM2](https://www.intel.com/content/www/us/en/developer/topic-technology/persistent-memory/overview.html), [PM4](https://pmem.io/pmdk/manpages/linux/v2.0/libpmem/pmem_is_pmem.3/) ## Three fictional 4 KiB fragments expose the coverage difference Consider one wholly fictional checkpoint requiring three distinct fragments: A, B and C. Each contains 4 KiB, or 4,096 bytes, of required new data at a different address range. All three target memory exposed for persistent use. At the stipulated interruption, A's new bytes reside only in processor caches, B's new bytes are in memory-controller write-pending queues, and C's new bytes are already in persistent media. Assume the platform implements the applicable documented ADR or eADR behavior, with its required energy support, and that the interruption meets that claim's conditions. The locations are supplied assumptions, not observations or assertions about queue capacity. The example does not assume that the fragments form a coherent checkpoint merely because the application requires all three. Against the stipulated ADR boundary, A is outside. B is pending within the covered controller queues, and C is already persistent. The distinct required data inside the boundary is B + C: 2 x 4,096 = 8,192 bytes, or 8 KiB. Of that total, 4 KiB is pending data whose preservation depends on the stipulated response. Against the stipulated eADR boundary, A joins B and C. The total becomes 3 x 4,096 = 12,288 bytes, or 12 KiB. Of that total, 8 KiB is pending in caches or controller queues; C supplies the same 4 KiB already in media. The change adds coverage for A's 4 KiB at this particular instant. It does not add physical capacity or establish that every possible pending write is covered. Counting distinct address ranges also avoids counting a cached copy and a media copy of the same data twice. For the buyer requiring all three fragments, the ADR claim leaves A's required new bytes uncovered by that mechanism. That is an evidence gap, not an observed loss result. The eADR stipulations close this location gap, leaving the fragments' consistency and recoverability to be established separately. ## Covered bytes still need an application consistency rule A report that software reached a particular store does not supply the location assumptions used in the example. The responsible software and platform owners need to connect the application's claimed progress point to the required bytes reaching the documented domain. Ordering also remains relevant when caches are covered. A claim about where pending data is protected does not describe which application changes must precede others. Intel's historical eADR discussion retains a software ordering requirement; expanding the domain does not remove that separate obligation. PMDK 2.0 provides another useful distinction. Its durability operation is explicitly neither atomic nor transactional. The documentation also explains that normal cache replacement can make some stores persistent before an application requests persistence. Software cannot assume that an entire set of changes waits together for one chosen moment. Return to A, B and C. Even if all three are covered, the location calculation contains no rule establishing that their contents represent the same application generation. Nor does it identify the metadata by which recovery locates and interprets them. A required fragment that was never produced cannot be supplied by a wider domain. The application owner therefore needs to explain the complete checkpoint contents, their relationship, the completion being acknowledged and the recovery interpretation. The linked training-checkpoint guide develops that application-state decision. The linked NVMe guide addresses command atomicity and persistent completion at a separate storage interface. References: [PM1](https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html), [PM3](https://pmem.io/pmdk/manpages/linux/v2.0/libpmem/pmem_flush.3/) ## Match the supplier's promise to the required pending bytes Suppose one historical-platform proposal says persistent memory installed, while another identifies the applicable OEM domain, the memory's persistent use and the conditions covering the required cache-held writes. The second gives the buyer evidence for a location-specific comparison. The first leaves that comparison open; its omission does not prove the hardware lacks protection. Ask the supplier to connect the exact server configuration and applicable documentation to the application's required destination and pending locations. Where the claim includes processor caches, the corresponding platform and stored-energy support need to be identified. Where the application promises a completed checkpoint, its software owner needs to connect that acknowledgement to the domain and consistency requirements. This turns a broad feature label into an assessable promise: which required new bytes are inside, which remain outside, and which have insufficient evidence. The historical references explain the distinction; they do not establish support or availability on another platform. The SSD power-loss-protection guide linked below covers drive-held buffers and mapping metadata. That protection can address another part of a storage design, but its boundary cannot answer whether this server's CPU-cache writes belong to its persistent-memory domain. ## An approved platform change can create a physical work package If the platform assessment leads to an approved server replacement, rack change or recabling task, Leviathan's Hardware Refresh & Physical Support service is relevant to that physical work. Its service page and project inquiry are linked below. Share a nonconfidential equipment summary, approved replacement identities, site, appointed parts supplier and intended physical changes. Agree the asset and connection records needed for handoff. The platform and application owners retain responsibility for persistence configuration, checkpoint behavior and return to service; the physical records document the agreed equipment work. References: [L1](https://www.leviathansystems.co/services/data-center-remediation) ## Primary sources - [PM1 — Intel: Third Generation Xeon Processor Scalable Family On Two Socket Platform Technical Overview](https://www.intel.com/content/www/us/en/developer/articles/technical/third-generation-xeon-scalable-family-overview.html). Checked 2026-10-20. ID 660365, updated March 21, 2021. The eADR section supplies the historical domain distinction, OEM energy dependency and retained ordering requirement. - [PM2 — Intel: Persistent Memory overview — Operating Modes](https://www.intel.com/content/www/us/en/developer/topic-technology/persistent-memory/overview.html). Checked 2026-10-20. The named Optane Memory Mode and App Direct Mode descriptions distinguish volatile use from persistent use; no current platform availability is inferred. - [PM3 — PMDK 2.0 libpmem: persistence and automatic CPU-cache flushing](https://pmem.io/pmdk/manpages/linux/v2.0/libpmem/pmem_flush.3/). Checked 2026-10-20. DESCRIPTION distinguishes durability from atomicity and transactions, notes early persistence through cache replacement, and describes automatic cache-flush coverage. Used conceptually, without prescribing operations. - [PM4 — PMDK 2.0 libpmem: persistent-memory mappings](https://pmem.io/pmdk/manpages/linux/v2.0/libpmem/pmem_is_pmem.3/). Checked 2026-10-20. DESCRIPTION and RETURN VALUE distinguish actual persistent-memory ranges from other mappings. The documented mapping-specific applicability is retained; no universal memory-detection claim is made. - [L1 — Leviathan Systems: Hardware Refresh & Physical Support](https://www.leviathansystems.co/services/data-center-remediation). Checked 2026-10-20. The physical lifecycle scope covers agreed equipment changes, recabling and handoff records, with separately assigned system and application responsibilities. ## Related Leviathan resources - [SSD power-loss protection: drive-held buffers and NAND](/articles/gpu-ssd-power-loss-protection-cache-nand) - [NVMe atomic writes, persistent completion and transactions](/articles/nvme-atomic-write-versus-persistence-and-transactions) - [Training checkpoints and storage snapshots: identify the application state](/articles/gpu-training-checkpoint-versus-storage-snapshot) - [Hardware Refresh & Physical Support](/services/data-center-remediation) - [Discuss the physical work around an approved server change](/contact?service=data-center-remediation&from=%2Farticles%2Fpersistent-memory-adr-eadr-power-failure-domain) ## Planning the physical work around an approved server change? Share the equipment summary, approved replacements, site, appointed parts supplier and requested physical changes to discuss scope and availability. [Discuss the scope](/contact?service=data-center-remediation&from=/articles/persistent-memory-adr-eadr-power-failure-domain)