Device Mapper – Wikipedia

Der Device Mapper ist ein Teil des Linux-Kernels (seit 2.6). Er erlaubt die Erzeugung virtueller blockorientierter Geräte, indem er deren Adressbereich auf andere blockorientierte Geräte oder spezielle Funktionen abbildet. Der Device Mapper wird vor allem für den Logical Volume Manager (LVM) und Geräteverschlüsselung genutzt. Der Device Mapper stellt einige Funktionen zur Verfügung, die LVM benötigt (und die in früheren Linux-Versionen integraler Bestandteil von LVM waren): Erzeugung und Verwaltung der blockorientierten Geräte, Snapshots (inklusive Zurückschreiben der Änderungen ins Ursprungsgerät ("Merge")) sowie diverse RAID-Funktionen (insbesondere Striping (Level 0) und Mirroring (Level 1)). Dank der Herauslösung aus LVM können diese Funktionen nun auch mit anderen blockorientierten Geräten (z. B. Festplatten(partitionen) und loop devices) genutzt werden. LVM und cryptsetup (LUKS) stellen Funktionen einer höheren Ebene zur Verfügung und schirmen den Benutzer so von den Details ab, die für den unmittelbaren Umgang mit dem Device Mapper (dmsetup) erforderlich sind. Geräte des Device Mappers können im laufenden Betrieb (beschreibbar eingehängtes Dateisystem) blockiert und weitgehend umkonfiguriert werden. Seit der Kernelversion 3.2^[1] unterstützt der Device Mapper auch Thin Provisioning. Ähnlich wie LVM setzt auch die Multipath-Funktion auf dem Device Mapper auf.

Geräte werden mit Hilfe des Device Mappers erzeugt, indem man dem Konsolenprogramm dmsetup neben dem Namen des Geräts folgende Daten übergibt:

1. Startsektor
2. Anzahl aufeinanderfolgender Sektoren mit demselben Ziel
3. Zieltyp (target)
4. zielspezifische Argumente

Die Definition eines Geräts kann aus einem einzelnen oder mehreren solchen Blöcken bestehen. So kann man mit der folgenden Konfiguration zwei Festplatten (je 100 GiB) zu einem einzigen logischen Laufwerk verbinden:

0 209715200 linear /dev/sdb 0
209715200 209715200 linear /dev/sdc 0

Die vom Device Mapper erzeugten Geräte erscheinen unter /dev/mapper/ mit dem dmsetup übergebenen Namen und unter /sys/block/ mit den Kernelnamen (dm-0, dm-1, ...).

Über dmsetup kann das Zusammenspiel der Manipulation von DM-Geräten mit udev gesteuert werden. Über den Daemon dmeventd kann außerdem auf Ereignisse reagiert werden, die DM-Geräte betreffen (etwa zur Neige gehender Speicherplatz bei thin provisioning).

LVM teilt dem Device Mapper mit, welche Blöcke auf einem Gerät in welcher Reihenfolge zu einem logischen Laufwerk gehören. Nach dem Anlegen des Geräts ist nicht mehr erkennbar, dass es sich um ein LVM-Gerät handelt; man könnte diese Zuweisung auch selber vornehmen. Zwei nacheinander per LVM erzeugte Laufwerke stellen sich im Device Mapper beispielsweise so dar:

1. 0 25165824 linear 8:8 384
2. 0 204800 linear 8:8 29360512

8:8 sind major und minor number für /dev/sda8, die zweite Zahl gibt die Größe an, die letzte den Offset zum Startsektor der Partition (nicht 0 wegen der LVM-Metadaten).

Dieser Abschnitt bezieht sich auf Snapshots von Volumes, die nicht Teil eines thin-pool Volumes sind, also auf das alte Verfahren. Snapshots werden meist per LVM erzeugt. Die LVM-Programme zeigen dann nur zwei Objekte an: das Ursprungslaufwerk und das Snapshotlaufwerk. Außerdem besteht derzeit die Restriktion, dass LVM nur Snapshotlaufwerke in derselben volume group wie das Ursprungslaufwerk anlegen kann. Dies ist eine Beschränkung des Verwaltungsprogramms (lvcreate), keine des Device Mappers. Aus dessen Sicht existieren nicht zwei, sondern vier Geräte (Snapshot vom logical volume (LV) test in der volume group (VG) vg0, Name des Snapshot-LV ist test-snap):

1. vg0-test
2. vg0-test-real
3. vg0-test--snap
4. vg0-test--snap-cow

Das ursprüngliche Gerät vg0-test wird vom Zieltyp linear umgeschrieben auf snapshot-origin, vg0-test-real hat die ursprüngliche Definition von vg0-test, unter vg0-test--snap wird die Snapshotsicht auf das Ursprungslaufwerk verfügbar gemacht, und vg0-test--snap-cow ist das Gerät, in dem per Copy-On-Write (COW) die nach Erzeugung des Snapshots am Ursprungsgerät vorgenommenen Änderungen protokolliert werden. Dies sind Snapshots auf Geräte-, nicht auf Dateisystemebene. Werden weitere Snapshots erzeugt, wird aus LVM-Sicht jeweils ein zusätzliches Laufwerk erzeugt, aus Sicht des Device Mappers jeweils zwei (Snapshot und COW).

LUKS-Volumes haben einen Header-Bereich (im folgenden Beispiel zwei MiB), der Rest speichert die verschlüsselten Daten. Die Verwaltungswerkzeuge lesen aus dem Header die nötigen Parameter und legen über den Rest ein mit diesen Parametern konfiguriertes DM-Volume. Ein LUKS-Volume muss kein LVM-Volume sein. Beispielhaft ein 100-MiB-Volume:

blockdev --getsz /dev/linux/lukstest

204800

Das von LUKS darin angelegte, verschlüsselte Volume ist etwas kleiner:

blockdev --getsz /dev/mapper/lukstest

200704

Der Device Mapper sieht das Volume folgendermaßen (Schlüssel gekürzt):

dmsetup table lukstest --showkeys

0 200704 crypt aes-cbc-essiv:sha256 bff5[...] 0 253:10 4096

Wie schon bei LVM (Snapshots) gehen bei LUKS die Möglichkeiten des Device Mappers (bzw. von dmsetup) über die der Verwaltungsprogramme hinaus. So ist es über die dmsetup-Funktionen load, suspend und resume möglich, die Größe eines eingehängten Volumes zu ändern, was cryptsetup nicht erlaubt.

Mit der Version 3.2 wurden die targets thin und thin-pool^[2] Bestandteil des Linux-Kernels. Diese targets funktionieren so, dass zunächst ein Volume für Metadaten (in der Größe des maximalen Ausbaus; 4 MiB Metadaten und 16 MiB Blockgröße reichen für etwa 1,3 TiB virtueller Kapazität) und eins für Daten (mindestens in der Größe des minimalen Ausbaus) erzeugt wird. Diese beiden Volumes werden dann über das target thin-pool verbunden. Der Pool kann mehrere Volumes (und Snapshots von diesen) enthalten. Diese werden über Nachrichten an das pool device erzeugt (dmsetup message). Im Gegensatz zu den sonstigen vom Device Mapper erzeugten Geräten kann das pool device nicht direkt als blockorientiertes Gerät beschrieben werden. Über das target thin werden dann die als normale blockorientierte Geräte ansprechbaren Objekte erzeugt (deren Größe später erhöht und verringert werden kann). Die Integration der Snapshotfunktion in das pool device reduziert nicht nur Speicherverbrauch auf den jeweils aktuell nötigen Wert (was eine größere Anzahl von Snapshots ermöglicht), sondern verringert durch eine interne Umorganisation der Snapshotverwaltung den Performanceverlust bei verketteten Snapshots. Mehrere Snapshots können sich Blöcke teilen, so dass nur einmal Speicherplatz belegt wird, die Daten aber in mehreren Volumes sichtbar sind.

Thin Provisioning unterstützt die primär für SSDs gedachte Funktion TRIM. Der Sinn dieser Funktion liegt allerdings nicht in den Eigenschaften und dem Schutz der darunter liegenden Hardware, sondern im Sparen von Speicherplatz, was wegen dessen Überbelegung von Bedeutung ist.

Der Device Mapper stellt neben den wichtigsten targets linear, crypt und snapshot/snapshot-origin eine Reihe spezieller targets^[3] zur Verfügung:

1. delay: führt Lese- und/oder Schreibzugriffe verzögert aus und kann sie auf mehrere Geräte verteilen
2. error: Erzeugt für jeden Zugriff einen I/O-Fehler (v. a. für Testzwecke)
3. flakey: erzeugt (konfigurierbar) Fehler bei Lese- und/oder Schreibzugriffen (ermöglicht das Verwerfen von Schreibzugriffen)
4. mirror: Spiegelung (RAID 1)
5. raid: für die höheren RAID-Level
6. snapshot-merge: an einem Snapshot vorgenommene Änderungen ins Originalvolume zurückschreiben (nicht im laufenden Betrieb mit dem Root-Dateisystem möglich)
7. striped: RAID 0
8. zero: liefert bei Lesezugriffen nur Nullen, verwirft Schreibzugriffe (blockorientierte Analogie zu /dev/null); kann zusammen mit Snapshots thin provisioning simulieren
9. (nicht im Vanilla-Kernel) ioband^[4]: erlaubt die Beschränkung der I/O-Bandbreite eines Geräts (auch pro User oder cgroup)

Professionelle Speichersysteme mit einem hohen Anspruch an Redundanz bieten analog zu RAID (dieselben Daten auf mehreren Geräten; Schutz vor dem Ausfall des eigentlichen Speichermediums) die Möglichkeit, auf unterschiedlichen Wegen auf dasselbe Speichermedium zuzugreifen (Schutz vor Ausfall eines der Geräte, die den Rechner mit dem Speichermedium verbinden). Dies wird vor allem bei Systemen auf Basis von Fibre Channel genutzt. Softwareseitig ist wichtig, dass das Speichermedium über einen festen Namen ansprechbar ist, der unabhängig davon ist, auf welchem Weg auf das Medium zugegriffen wird. Dies wird über das target multipath erreicht, das über viele Optionen konfiguriert werden und dadurch sogar Geschwindigkeitsunterschiede zwischen alternativen Wegen zum Speichermedium ausgleichen kann.

• Webseite des Device Mappers
• Zusammenspiel von LVM und Device Mapper am Beispiel der Datenrettung nach einem LVM-Crash
• man page für dmsetup
• Website der multipath-tools

1. ↑ Artikel bei Heise online. Abgerufen am 26. Februar 2012. 
2. ↑ Dokumentation des Entwicklers. Abgerufen am 26. Februar 2012. 
3. ↑ Kerneldokumentation. Abgerufen am 26. Februar 2012. 
4. ↑ Projektseite bei sourceforge. Archiviert vom Original (nicht mehr online verfügbar) am 10. Mai 2012; abgerufen am 26. Februar 2012.