Documentation/driver-api/nvdimm/btt.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/nvdimm/btt.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/nvdimm/btt.rst
Extension
.rst
Size
12053 bytes
Lines
285
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

=============================
BTT - Block Translation Table
=============================


1. Introduction
===============

Persistent memory based storage is able to perform IO at byte (or more
accurately, cache line) granularity. However, we often want to expose such
storage as traditional block devices. The block drivers for persistent memory
will do exactly this. However, they do not provide any atomicity guarantees.
Traditional SSDs typically provide protection against torn sectors in hardware,
using stored energy in capacitors to complete in-flight block writes, or perhaps
in firmware. We don't have this luxury with persistent memory - if a write is in
progress, and we experience a power failure, the block will contain a mix of old
and new data. Applications may not be prepared to handle such a scenario.

The Block Translation Table (BTT) provides atomic sector update semantics for
persistent memory devices, so that applications that rely on sector writes not
being torn can continue to do so. The BTT manifests itself as a stacked block
device, and reserves a portion of the underlying storage for its metadata. At
the heart of it, is an indirection table that re-maps all the blocks on the
volume. It can be thought of as an extremely simple file system that only
provides atomic sector updates.


2. Static Layout
================

The underlying storage on which a BTT can be laid out is not limited in any way.
The BTT, however, splits the available space into chunks of up to 512 GiB,
called "Arenas".

Each arena follows the same layout for its metadata, and all references in an
arena are internal to it (with the exception of one field that points to the
next arena). The following depicts the "On-disk" metadata layout::


    Backing Store     +------->  Arena
  +---------------+   |   +------------------+
  |               |   |   | Arena info block |
  |    Arena 0    +---+   |       4K         |
  |     512G      |       +------------------+
  |               |       |                  |
  +---------------+       |                  |
  |               |       |                  |
  |    Arena 1    |       |   Data Blocks    |
  |     512G      |       |                  |
  |               |       |                  |
  +---------------+       |                  |
  |       .       |       |                  |
  |       .       |       |                  |
  |       .       |       |                  |
  |               |       |                  |
  |               |       |                  |
  +---------------+       +------------------+
                          |                  |
                          |     BTT Map      |
                          |                  |
                          |                  |
                          +------------------+
                          |                  |
                          |     BTT Flog     |
                          |                  |
                          +------------------+
                          | Info block copy  |
                          |       4K         |
                          +------------------+

Annotation

Implementation Notes