linux/Documentation/device-mapper/persistent-data.txt
<<
>>
Prefs
   1Introduction
   2============
   3
   4The more-sophisticated device-mapper targets require complex metadata
   5that is managed in kernel.  In late 2010 we were seeing that various
   6different targets were rolling their own data structures, for example:
   7
   8- Mikulas Patocka's multisnap implementation
   9- Heinz Mauelshagen's thin provisioning target
  10- Another btree-based caching target posted to dm-devel
  11- Another multi-snapshot target based on a design of Daniel Phillips
  12
  13Maintaining these data structures takes a lot of work, so if possible
  14we'd like to reduce the number.
  15
  16The persistent-data library is an attempt to provide a re-usable
  17framework for people who want to store metadata in device-mapper
  18targets.  It's currently used by the thin-provisioning target and an
  19upcoming hierarchical storage target.
  20
  21Overview
  22========
  23
  24The main documentation is in the header files which can all be found
  25under drivers/md/persistent-data.
  26
  27The block manager
  28-----------------
  29
  30dm-block-manager.[hc]
  31
  32This provides access to the data on disk in fixed sized-blocks.  There
  33is a read/write locking interface to prevent concurrent accesses, and
  34keep data that is being used in the cache.
  35
  36Clients of persistent-data are unlikely to use this directly.
  37
  38The transaction manager
  39-----------------------
  40
  41dm-transaction-manager.[hc]
  42
  43This restricts access to blocks and enforces copy-on-write semantics.
  44The only way you can get hold of a writable block through the
  45transaction manager is by shadowing an existing block (ie. doing
  46copy-on-write) or allocating a fresh one.  Shadowing is elided within
  47the same transaction so performance is reasonable.  The commit method
  48ensures that all data is flushed before it writes the superblock.
  49On power failure your metadata will be as it was when last committed.
  50
  51The Space Maps
  52--------------
  53
  54dm-space-map.h
  55dm-space-map-metadata.[hc]
  56dm-space-map-disk.[hc]
  57
  58On-disk data structures that keep track of reference counts of blocks.
  59Also acts as the allocator of new blocks.  Currently two
  60implementations: a simpler one for managing blocks on a different
  61device (eg. thinly-provisioned data blocks); and one for managing
  62the metadata space.  The latter is complicated by the need to store
  63its own data within the space it's managing.
  64
  65The data structures
  66-------------------
  67
  68dm-btree.[hc]
  69dm-btree-remove.c
  70dm-btree-spine.c
  71dm-btree-internal.h
  72
  73Currently there is only one data structure, a hierarchical btree.
  74There are plans to add more.  For example, something with an
  75array-like interface would see a lot of use.
  76
  77The btree is 'hierarchical' in that you can define it to be composed
  78of nested btrees, and take multiple keys.  For example, the
  79thin-provisioning target uses a btree with two levels of nesting.
  80The first maps a device id to a mapping tree, and that in turn maps a
  81virtual block to a physical block.
  82
  83Values stored in the btrees can have arbitrary size.  Keys are always
  8464bits, although nesting allows you to use multiple keys.
  85
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.