Documentation/admin-guide/device-mapper/persistent-data.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/device-mapper/persistent-data.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/device-mapper/persistent-data.rst
Extension
.rst
Size
3013 bytes
Lines
89
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

===============
Persistent data
===============

Introduction
============

The more-sophisticated device-mapper targets require complex metadata
that is managed in kernel.  In late 2010 we were seeing that various
different targets were rolling their own data structures, for example:

- Mikulas Patocka's multisnap implementation
- Heinz Mauelshagen's thin provisioning target
- Another btree-based caching target posted to dm-devel
- Another multi-snapshot target based on a design of Daniel Phillips

Maintaining these data structures takes a lot of work, so if possible
we'd like to reduce the number.

The persistent-data library is an attempt to provide a re-usable
framework for people who want to store metadata in device-mapper
targets.  It's currently used by the thin-provisioning target and an
upcoming hierarchical storage target.

Overview
========

The main documentation is in the header files which can all be found
under drivers/md/persistent-data.

The block manager
-----------------

dm-block-manager.[hc]

This provides access to the data on disk in fixed sized-blocks.  There
is a read/write locking interface to prevent concurrent accesses, and
keep data that is being used in the cache.

Clients of persistent-data are unlikely to use this directly.

The transaction manager
-----------------------

dm-transaction-manager.[hc]

This restricts access to blocks and enforces copy-on-write semantics.
The only way you can get hold of a writable block through the
transaction manager is by shadowing an existing block (ie. doing
copy-on-write) or allocating a fresh one.  Shadowing is elided within
the same transaction so performance is reasonable.  The commit method
ensures that all data is flushed before it writes the superblock.
On power failure your metadata will be as it was when last committed.

The Space Maps
--------------

dm-space-map.h
dm-space-map-metadata.[hc]
dm-space-map-disk.[hc]

On-disk data structures that keep track of reference counts of blocks.
Also acts as the allocator of new blocks.  Currently two
implementations: a simpler one for managing blocks on a different
device (eg. thinly-provisioned data blocks); and one for managing
the metadata space.  The latter is complicated by the need to store
its own data within the space it's managing.

The data structures
-------------------

Annotation

Implementation Notes