NVDIMM(4)

📦 version 15.1, in freebsd 14.5, freebsd 15.1, nixpkgs unstable

✨ NVDIMM(4) ✨ — the ACPI NVDIMM driver, bestie edition 💅

Okay so this is from the amd64 Kernel Interfaces Manual, and it's literally giving hardware realness. Buckle up, bestie, we're learning about persistent memory 🫶.

💅 SYNOPSIS

To load the driver as a module at boot, place the following line in loader.conf(5):

nvdimm_load="YES"

That's it. That's the whole synopsis. Slay.

🌸 DESCRIPTION

Note: The nvdimm driver is under development and has some important limitations described below. Don't say I didn't warn you 💀.

The nvdimm driver provides access to Non-Volatile DIMM (NVDIMM) persistent memory devices, which are ACPI-enumerated under the root NVDIMM device with a _HID of ACPI0012 and in the NFIT table. Like, the firmware literally points at them and says "here, have some memory" ✨.

For each System Physical Address (SPA) Range described by NFIT, a device node /dev/nvdimm_spaNNN is created, where NNN is the SPA position in the table. This node can be used to read(2), write(2), or mmap(2) the device. Yep, you can just raw-dog it with syscalls if that's your vibe 🦋.

Also, for each SPA, the geom provider spaNNN is created, which can be used to create a conventional filesystem (e.g., by newfs(8)) and mount(8) it as any storage volume. Content accessible by /dev/nvdimm_spaNNN and /dev/spaNNN is coherent. Like literally the same data, no cap 🔥.

The nvdimm driver has support for reading NVDIMM namespaces (if supported by your hardware and already configured by some other mechanism, e.g., a BIOS configuration screen). For each namespace in a SPA, the driver provides a /dev/nvdimm_spaNNNnsMMM device node and spaNNNnsMMM geom provider, which behave analogously to their full-SPA cousins described above. Basically they're the little siblings and they're iconic in their own right 🎀.

🦋 SEE ALSO

Go read those if you want the full lore. Iykyk 💜.

💖 HISTORY

The nvdimm driver first appeared in FreeBSD 12.0. A whole era 👑.

👑 AUTHORS

The nvdimm driver was originally written by Konstantin Belousov <kib@FreeBSD.org>, and then updated by D. Scott Phillips <scottph@FreeBSD.org>. Absolute legends, both of them 🫶.

💀 BUGS

Okay so there are some real ones, bestie, listen up:

  • The nvdimm driver does not utilize the Block Window interface, so if a write to an NVDIMM is interrupted due to a system crash or power outage, the corresponding page might be left in a partially updated state. Like, torn writes are a thing and they're not cute 😭.
  • There is no support for Device-Specific Methods (DSM), used to report and control device health and wearing. So you can't check your memory's health like you check your skin routine. Tragic.
  • The driver depends on the pmap_largemap(9) pmap interface, which is currently only implemented on amd64. The interface can only be reasonably implemented on 64-bit architectures. So like, don't expect this on your 32-bit ancient artifact, bestie 💅.

And that's the tea ☕. This whole masterpiece is from the Debian edition, dated September 5, 2019, and the page is NVDIMM(4) — periodt. Go forth and use persistent memory responsibly, mwah 💋✨.

📦 where this page comes from