Device Mapper

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.

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. Dafür gibt es zwei Mechanismen:

• Device-Mapper-Geräte haben zwei Tabellen. Im laufenden Betrieb kann die inaktive Tabelle geladen und dann zwischen den beiden umgeschaltet werden. Dafür wird zunächst der normale Zugriff auf das Gerät gestoppt: Alle zu dem Zeitpunkt diesem Gerät zugewiesenen I/O requests werden noch auf die alte Tabelle geschrieben. Ab diesem Moment entstehende I/O requests werden blockiert. Dies entspricht diesen drei Kommandoaufrufen:
  • dmsetup reload
  • dmsetup suspend
  • dmsetup resume
• Nachrichten an das Gerät. Mit dmsetup message können (je nach Target) Nachrichten an ein Device-Mapper-Gerät geschickt werden. So werden thin snapshots nicht über eine neue Tabellenkonfiguration erzeugt, sondern über solche Nachrichten.

Seit der Kernelversion 3.2 unterstützt der Device Mapper auch Thin Provisioning. Ähnlich wie LVM setzt auch die Multipath-Funktion (außer bei NVMes) auf dem Device Mapper auf. Device Mapper kann Trim- / Discard-Befehle an das übergeordnete Gerät durchreichen.

Aufbau von Geräten des Device Mappers

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).

Über

• dmsetup ls
• dmsetup ls --tree und
• ls -ld /sys/devices/virtual/block/dm-*

kann man sich die bestehenden Device-Mapper-Geräte anzeigen lassen. Mit

• dmsetup deps
• dmsetup info
• dmsetup status
• dmsetup table

kann man sich Informationen über ein Gerät anzeigen lassen.

Zusammenhang von Device Mapper und LVM

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 (mit dmsetup). 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).

Aufbau von Snapshots

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).

Zusammenhang von Device Mapper und LUKS

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.

Thin Provisioning

Mit der Version 3.2 wurden die Targets thin und thin-pool 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.

Thin Provisioning kann auch als eine Art Snapshot über ein Nur-Lese-Blockgerät gelegt werden.

RAID

Device Mapper nutzt die MD-Funktionen (SoftRAID, multiple devices). Frühere Versionen hatten ein gesondertes mirror Target. LVM kann (mit lvconvert) Geräte im alten Format ins neue konvertieren.

Caching

Der Device Mapper unterstützt Caching (etwa auf einer NVMe für eine größere HDD) über zwei Targets, die beide über LVM genutzt werden können:

• dm-cache
• dm-writecache

dm-cache kann Lese- und Schreibzugriffe cachen; es kann auf writeback und writethrough konfiguriert werden.

dm-writecache cacht keine Lesezugriffe und puffert Schreibzugriffe. Wie lange diese maximal gepuffert werden und ab welchem Füllstand automatisch Daten auf das Originalgerät zurückgeschrieben werden, kann konfiguriert werden.

Multipath

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.

Targets

Device Mapper Targets und interne Komponenten

	Target	via LVM	Funktion
direkte Abbildung des Speichers auf ein anderes Gerät	linear	ja	Abbildung auf einen oder mehrere Bereiche eines Blockgeräts
	zoned	nein	präsentiert eine Zonen-Festplatte (SCSI: Zoned Block Command (ZBC); ATA: Zoned-device ATA command set (ZAC)) als normales Blockgerät und führt die nötigen Anpassungen zur Vermeidung eines Geschwindigkeits-Einbruchs im Hintergrund durch
	ebs	nein	entspricht linear, aber emuliert ein Blockgerät mit kleinerer Blockgröße
	era	nein	entspricht linear, aber erfasst für die einzelnen Regionen des Speichers, wann sie zuletzt beschrieben wurden
	multipath	nein	Multipath
Abbildung des Speichers auf mehrere Geräte	striped	ja	nichtredundante Verteilung der Daten auf mehrere Geräte; entspricht RAID-Level 0
	raid	ja	RAID-Level 0, 1, 4, 5 (diverse Varianten), 6 (diverse Varianten), 10
	unstriped	nein	Umkehrung von striped, um logisch auf ein Ursprungsgerät zugreifen zu können, ohne direkt physisch darauf zugreifen zu müssen
	switch	nein	entspricht linear, aber für eine riesige Anzahl von Speicherbereichen, so dass die Verwendung von linear ineffizient wäre
(thickLVM) Snapshots	snapshot-origin	ja	Vorbereitung eines Blockgeräts für die Erstellung von Snapshots
	snapshot	ja	Erstellen eines Snapshots (mehrere können gleichzeitig existieren)
	snapshot-merge	ja	Übernahme der seit dem Snapshot geschriebenen Daten in das Ursprungsgerät
thin provisioning	thin-pool	ja	Thin-Provisioning-Speicherpool und -Metadaten (mit Snapshots); Vorbereitung für die Erstellung eines Thin-Provisioning-Blockgeräts
	thin	ja	Thin-Provisioning-Blockgerät
	vdo	ja	virtual data optimizer: Deduplikation
Caching	cache	ja	Lese- (writethrough) oder Schreib-Lese-Cache (writeback)
	writecache	ja	Schreibpuffer / Schreibcache
	clone	nein	Kopiert den Inhalt eines (langsamen) Nur-lese-Blockgeräts bei jedem Lese- oder Schreibzugriff auf einen neuen Speicherbereich
	pcache	nein	Ermöglicht den (Cache-)Zugriff auf DAX-Speicher
Verschlüsselung / Integritätssicherung	crypt	nein	Verschlüsselung (v. a. für LUKS); kann in Kombination mit dm-integrity die Hashwerte verschlüsseln, so dass ein Offline-Angreifer (ohne den Schlüssel) die Daten nicht unbemerkt verändern kann
	integrity	ja	Sicherung der einzelnen Blöcke mit Hashwerten (können von dm-crypt bereitgestellt werden) oder Prüfsummen auf einem beschreibbaren Gerät
	ima	nein	Interface diverser Device-Mapper-Targets zur Linux Integrity Measurement Architecture
	verity	nein	Sicherung eines kompletten Nur-lese-Blockgeräts mit einem Hash-Baum (v. a. fürs Booten)
Tests / Debugging	delay	nein	führt Lese- und/oder Schreibzugriffe verzögert aus und kann sie auf mehrere Geräte verteilen
	dust	nein	Erzeugt für konfigurierbare Sektoren einen I/O-Fehler, der nach einem Schreibzugriff nicht mehr auftritt (emuliert das Remapping von Ersatzsektoren in Festplatten)
	error	nein	Erzeugt für jeden Zugriff einen I/O-Fehler
	flakey	nein	erzeugt (konfigurierbar) Fehler bei Lese- und/oder Schreibzugriffen (ermöglicht das Verwerfen von Schreibzugriffen)
	log-writes	nein	reicht Schreibzugriffe an ein Blockgerät durch und loggt sie auf einem anderen; v. a. für die Entwicklung von Dateisystemen
	zero	nein	liefert bei Lesezugriffen nur Nullen, verwirft Schreibzugriffe (blockorientierte Analogie zu /dev/null); kann zusammen mit Snapshots thin provisioning simulieren
Spezialhardware	inlinecrypt	nein	Verschlüsselungshardware in Android-Smartphones
	pcache	nein	Ermöglicht den (Cache-)Zugriff auf DAX-Speicher
Device-Mapper-interne Funktionen (keine Targets für dmsetup)	log	-	Logging
	io	-	Verteilung von Zugriffen pro Region des Speichers synchron oder asynchron auf eins oder mehrere Blockgeräte
	kcopyd	-	asynchrones Kopieren (für snapshot)
	persistent data	-	Infrastruktur für das einheitliche Speichern von Metadaten für mehrere DM-Module; enthält: dm-block-manager, dm-transaction-manager, dm-space-map, dm-space-map-metadata, dm-space-map-disk, dm-btree, dm-btree-remove, dm-btree-spine, dm-btree-internal
	queue-length	-	Pfadauswahl für Multipath (nach Länge der Warteschlange)
	service-time	-	Pfadauswahl für Multipath (nach Dauer der Zugriffe)

Weblinks

• Kerneldokumentation 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