NVMe power-loss protection: knowing whether your drive has PLP at all

Power-loss protection (PLP) is the difference between an unsafe shutdown being a non-event and an unsafe shutdown being silent data corruption. Enterprise NVMe drives carry capacitors that hold the controller up long enough to flush the volatile write cache to NAND when power drops. Consumer drives do not. On a drive without PLP, every power loss, PSU failure, or hard reset risks losing writes that the kernel and the application already believe are durable.

PLP is a procurement-time property, not a runtime signal. There is no SMART field that says “this drive has no PLP.” The critical_warning bit 4 (volatile memory backup failed) only fires when a drive that has a PLP capacitor reports that the capacitor has failed. A drive that never had PLP never sets the bit. The absence of PLP is silent, which is why it surfaces as a surprise during post-incident review: the team assumed the drives were protected, and nothing ever told them otherwise.

This article covers how to determine PLP capability conclusively, how to baseline it at provisioning, and which runtime signals matter afterward.

Why SMART cannot tell you

The NVMe SMART/Health Information log reports what the controller knows about its own health, not what hardware it was built with. A consumer drive without capacitors considers itself perfectly healthy, because it is operating exactly as designed.

The closest SMART gets to this topic is critical_warning bit 4. Per the spec, that bit means the volatile memory backup device has failed, and it is only valid on controllers that have a volatile memory backup solution in the first place. So bit 4 answers a different question than the one most operators think it answers:

• Bit 4 set: the drive has PLP, and the PLP capacitor or its charge circuit has failed. In-flight writes are now unprotected. This is a ticket-level risk escalation, not an active fault.
• Bit 4 clear: either the drive has working PLP, or the drive has no PLP at all. SMART does not distinguish these two cases.

That second case is the trap. If your alerting posture is “page on nonzero critical_warning,” you will never be paged about a fleet of consumer drives running write-intensive production workloads unprotected. Detection has to happen out of band, at provisioning time, using the Identify Controller data.

What PLP actually protects

When an application issues a write and it completes, the data has not necessarily reached NAND. The typical path is:

1. The host submits the write to the submission queue.
2. The controller accepts the data into its internal write cache (DRAM or SRAM).
3. The controller posts the completion entry. The host considers the write done.
4. The controller destages the data to NAND in the background.

Step 3 before step 4 is the window. If power is lost between completion and destage, the acknowledged write is gone. On a drive with PLP, capacitors keep the controller alive for the milliseconds needed to flush that cache to NAND, so the completion was honest. On a drive without PLP, the cache is volatile and the window is real.

Filesystems and databases defend against this with flush commands (fsync, journal barriers). A flush forces the controller to persist the cache before acknowledging. That mechanism is only as trustworthy as the drive’s flush implementation, which matters later in this article.

One related distinction: some consumer drives advertise “power loss immunity” or sudden power-off recovery features. These protect data already at rest on NAND from being corrupted by a mid-program power cut. They do not protect in-flight writes sitting in the volatile cache. Only capacitor-backed hardware PLP covers the in-flight window.

How to check whether a drive has PLP

Run these checks at provisioning, record the result per drive model in your inventory, and re-check whenever hardware or firmware changes. All commands are read-only.

Step 1: read the Volatile Write Cache field from Identify Controller

# Check the VWC field in Identify Controller data
nvme id-ctrl /dev/nvme0 -H | grep -i cache

The VWC field reports whether the controller has a volatile write cache. This is where the inversion lives:

• Volatile Write Cache Present: the drive has a volatile cache. There is no capacitor making it non-volatile, so the drive does not have hardware PLP. Typical for consumer drives.
• Volatile Write Cache Not Present: the cache is not volatile, because the controller can guarantee the cache contents reach non-volatile media on power loss. The NVMe spec treats such a cache as non-volatile, and the Volatile Write Cache feature does not apply to it. This is the signature of an enterprise drive with PLP.

The counterintuitive part: “Not Present” is the good answer. Operators routinely misread “Volatile Write Cache Not Present” as a missing feature. It is the opposite.

Step 2: probe the Volatile Write Cache feature

# Read Feature ID 0x06 (Volatile Write Cache)
nvme get-feature /dev/nvme0 -f 0x06

On a drive with a volatile write cache, this succeeds and returns the current state (enabled or disabled). On an enterprise drive with PLP, this command fails with a status like Invalid Field in Command, because the feature does not exist for a non-volatile cache. That failure is the expected and desired answer, not a drive malfunction. Do not open a ticket with the vendor over it.

Step 3: cross-check the kernel’s view

# Check the block-layer write cache view
cat /sys/block/nvme0n1/queue/write_cache

The Linux block layer reports write back for a device with a volatile write cache and write through for one without. A drive reporting write through here, combined with “Volatile Write Cache Not Present” from step 1 and a failing get-feature -f 0x06 from step 2, is a consistent PLP picture from three independent angles.

flowchart TD
    A[nvme id-ctrl: VWC field] --> B{Volatile write cache present?}
    B -->|Yes| C[No hardware PLP]
    B -->|No| D[Cache is non-volatile: PLP present]
    C --> E[get-feature -f 0x06 returns state]
    C --> F[sysfs write_cache: write back]
    D --> G[get-feature -f 0x06: Invalid Field]
    D --> H[sysfs write_cache: write through]
    D --> I[Monitor critical_warning bit 4 for capacitor failure]
    C --> J[Every unsafe shutdown risks acknowledged writes]

Step 4: record it

PLP capability does not change at runtime, but your fleet does. Record per drive model:

• PLP capability from steps 1-3. This determines the blast radius of every future unsafe shutdown.
• Volatile write cache state for drives that have one, as a baseline. A cache that gets disabled later (or enabled on a drive you expected to be cache-off) changes both performance and durability semantics, and an unexpected change from baseline is worth a ticket.
• Drive class (consumer vs enterprise) alongside it. Consumer drives also differ in endurance, overprovisioning, and thermal behavior, so the monitoring posture should differ as a group, not just on this one axis. See the playbook-level discussion in the hub at /guides/nvme/.

Interpreting the results

If the three signals disagree, trust the Identify Controller data first and re-run the checks. Mixed results are unusual and worth investigating before the drive goes into production.

Drives without PLP: what changes operationally

If the check shows no PLP, you have options, none of which are free:

• Move write-critical data off the drive. Databases with synchronous commit, WALs, and journal devices are the worst tenants for a drive without PLP. Bulk read-mostly or reconstructable data is a better fit.
• Accept the risk explicitly and monitor unsafe_shutdowns as a data-loss exposure counter. Each increment on a drive without PLP is a window where acknowledged writes may have been lost. After any increment, verify filesystem and application integrity before declaring the incident over. The corruption typically shows up at the filesystem or application layer, not as drive-level errors.
• Verify flush behavior before trusting fsync. The durability story on a drive without PLP rests entirely on flush commands doing what the spec requires. Independent testing has found consumer drives that lost flushed data on power loss, so treat flush correctness as a property of the specific drive model, not of the interface. If the workload cannot tolerate losing acknowledged writes, the honest fix is a drive with PLP.
• Be extra careful with DRAM-less drives. Drives that use Host Memory Buffer borrow host RAM for FTL tables over PCIe. On power loss the link drops instantly, so the mapping state in host memory is gone with no chance of any capacitor helping. These drives are the most exposed class.

Disabling the volatile write cache on a drive that has one is also an option: it closes the durability window at the cost of write performance. Whether that trade is worth it depends on the workload, and it should be a deliberate, documented decision rather than an accident of a tuning script.

Signals to watch in production

Once PLP capability is baselined, the runtime work is monitoring the signals that interact with it.

On drives with PLP, bit 4 is the key signal: the drive keeps performing normally after the capacitor fails, so there is no performance symptom. The only indication is the SMART bit, which is why per-bit critical_warning alerting matters. A blanket “critical_warning != 0” alert will at least catch it, but it will not tell the on-call what changed or why the severity is “risk escalation” rather than “drive dying.”

How Netdata helps

• Netdata exposes each critical_warning bit as its own dimension in nvme.device_critical_warnings_state, including volatile_mem_backup_failed for bit 4, so a PLP capacitor failure is alertable independently of the other bits.
• nvme.device_unsafe_shutdowns_count tracks the unsafe shutdown counter over time, so a new power-loss event is visible immediately rather than discovered during a later SMART review.
• Correlating an unsafe shutdown increment with the media_errors rate helps distinguish a benign power event from one that left damage behind.
• Because Netdata polls SMART continuously, you can see the timeline of a power event against temperature, throughput, and error signals on the same drive, which shortens the “did we lose data” investigation.
• The durable answer to “does this drive have PLP” still comes from the provisioning-time checks above. Netdata’s role is catching the capacitor failure and the unsafe shutdowns afterward.

Related guides

• NVMe critical_warning is nonzero: decoding the SMART critical warning bitmask
• NVMe available spare below threshold: critical warning bit 0 and end-of-life wear
• NVMe available spare declining: watching the wear trajectory before the threshold
• NVMe endurance runway: projecting time-to-replacement from wear signals
• NVMe error log entries growing: num_err_log_entries beyond media errors
• nvme nvme0: I/O timeout, Resetting controller: what an NVMe controller reset means