Device Mapper: Explanation & Insights

The kernel's universal block-device adapter — and the one engine hiding under LVM, LUKS, and multipath alike.

What It Is

Device mapper — usually shortened to dm — is a kernel framework that takes one block device and presents it as another. That's the whole idea in a sentence: an input device goes in, a transformed device comes out, and everything above (the filesystem, the application, you) talks to the output as if it were an ordinary disk. The transformation can be almost anything — encrypt every block on the way through, stitch several disks into one, hand back a snapshot frozen at a moment in time, retry a read down a second cable if the first one fails. Device mapper itself doesn't care which; it just provides the plumbing and lets pluggable modules called targets decide what actually happens to the bytes.

If you're new to running servers, here's the orientation that makes the rest of this page click. When you look at a Linux box, you see physical disks like /dev/sda at the bottom and mounted filesystems at the top. Device mapper is the layer in between where the interesting rearranging happens. A raw partition is dull — it's just a contiguous run of sectors. Device mapper is what lets that boring slab become an encrypted volume, or a resizable logical volume, or a member of a fault-tolerant pair, without the filesystem above ever knowing anything changed. It is, in the most literal sense, a mapper of devices: a function from blocks to blocks, implemented in the kernel, fast enough that you never feel it.

Here's the thing almost every tutorial leaves muddy, and it's the whole reason this page exists. People learn LVM as one product, LUKS disk encryption as another, multipath as a third, software RAID as a fourth — four separate manuals, four separate mental models. They are not separate. They are all device-mapper targets stacked on the same engine. LVM is dm. LUKS is dm. Multipath is dm. dm-cache is dm. Snapshots are dm. The famous tools are thin user-space wrappers that load a table into the kernel telling device mapper which target to use and how to configure it. Once you see that, the storage stack stops being a pile of unrelated technologies and becomes one idea, applied over and over. This page is here to make you see it.

Why It Matters

You will almost never type the word dmsetup. You'll run lvm tools, cryptsetup, multipath — the high-level commands — and they'll quietly build dm devices for you. So why learn the layer underneath at all?

Because the day something goes wrong, the abstractions leak. A logical volume won't activate. A umount fails with "device is busy" and you can't figure out who's holding it. An encrypted volume refuses to close because something invisible is layered on top of it. A leftover mapping from a half-finished migration is squatting on a disk you want to repartition, and every tool insists the disk is in use. In every one of these moments, the high-level tool shrugs and you drop down to device mapper to see the actual truth — what is mapped onto what, in what order, and what is still holding a reference. Understanding dm turns these from a panicked forum search into a thirty-second diagnosis.

It also matters because the stacking is invisible by default, and invisible infrastructure is exactly the kind that surprises you. A filesystem reporting I/O errors might be perfectly healthy — the fault is two layers down in a RAID member or a flaky cable that multipath is masking. Knowing that several dm targets sit between your df output and the spinning metal is what stops you replacing the wrong thing.

It's Targets All the Way Down

Let's make the central idea concrete, because it's the payoff of the whole page. Device mapper ships a catalogue of targets, each a small kernel module implementing one kind of block transformation. Here are the ones you'll actually meet on a Linux server:

dm-linear — the simplest target imaginable: map a range of the output device onto a range of some input device, one-to-one. Boring alone, but concatenate several dm-linear mappings and you can glue three disks end-to-end into one larger device. This is the brick LVM is built from: an ordinary logical volume is almost always just dm-linear segments pointing at chunks of your physical disks.
dm-stripe — interleave blocks across several devices for parallel throughput. This is how an LVM striped volume (and RAID 0) gets its speed.
dm-crypt — encrypt and decrypt every block as it passes through. This is LUKS disk encryption. cryptsetup luksOpen does nothing magical: it reads the key, then loads a dm-crypt table into the kernel. The cleartext device that appears under /dev/mapper/ is a dm device whose target happens to scramble bytes.
dm-thin / dm-thin-pool — thin provisioning and the cheap, instant snapshots LVM offers. Allocate space only when it's actually written; share unchanged blocks between a volume and its snapshot.
dm-snapshot — the older copy-on-write snapshot mechanism: freeze a volume, record only what changes afterward.
dm-cache — put a fast SSD in front of a slow HDD and let dm keep hot blocks on the fast tier. (bcache solves the same problem outside dm; dm-cache solves it as a target.)
dm-multipath — when a SAN disk is reachable over two cables/controllers, present the two paths as one device and fail over transparently. Pure dm.
dm-raid — software RAID levels (1/4/5/6/10) implemented as a dm target, the bridge that lets LVM offer RAID volumes directly. (Note the cousin below — Linux has two software-RAID engines, and this is the dm-flavoured one.)
dm-integrity, dm-verity, dm-delay, dm-zero, dm-error — checksums per block, read-only authenticated volumes (Android and secure-boot images lean on dm-verity), and a few deliberately silly ones used for testing.

Stand back and look at that list. Encryption, volume management, snapshots, caching, multipath failover, RAID — products you'd buy or download separately on other platforms — are, on Linux, the same engine wearing different hats. The user-space tools (cryptsetup, the lvm suite, multipath) exist mostly to compute the right table and hand it to the kernel. Underneath, it really is targets all the way down: stack a dm-crypt on top of a dm-linear on top of a dm-raid, and the bytes flow through each in turn, every one of them just a block-in/block-out function. Once that clicks, half of Linux storage stops being a zoo and becomes a single well-designed idea you can reason about.

Note

Linux confusingly has two software-RAID implementations. The classic one is md (multiple devices), driven by mdadm and visible in /proc/mdstat — that's a separate kernel subsystem, not device mapper. The newer dm-raid target reuses the md RAID engine but exposes it through device mapper so LVM can manage RAID volumes natively. Same maths, two front doors. If you created the array with mdadm, it's md; if you created it with lvcreate --type raid1, it's dm. The historical "dmraid" tool for fakeRAID/BIOS-RAID is a third, mostly-retired thing — don't confuse it with dm-raid the target.

How a Mapping Actually Works

Every dm device is defined by a table: a list of lines, one per target segment, each saying "for this range of logical sectors, send I/O to this target, configured like this." The format is <start> <length> <target-type> <target-args>. The kernel reads the table once when the device is created, builds the routing, and from then on every read and write is dispatched through it at full speed — no per-I/O parsing, just a function call into the target module.

A plain linear volume's table is about as simple as it gets:

0 41943040 linear 8:17 2048

Read it left to right: starting at logical sector 0, for 41943040 sectors (that's 20 GiB), use the linear target, pointing at device major:minor 8:17 (which is /dev/sdb1) beginning at sector offset 2048. That single line is a 20 GiB logical volume. An encrypted device's table instead names the crypt target plus the cipher and a key reference; a striped volume's table names striped with the chunk size and the list of underlying devices. The principle never changes — a table maps logical sectors to a target, and the target decides what to do with them.

The devices themselves appear under /dev/mapper/, with friendly names the high-level tools choose: /dev/mapper/cryptroot, /dev/mapper/vg0-data, /dev/mapper/mpatha. Those are symlinks (or device nodes) backed by an actual kernel device usually called /dev/dm-0, /dev/dm-1, and so on — the dm-N is the kernel's internal name, the /dev/mapper/ name is the human one. LVM uses a vgname-lvname convention (a literal hyphen in a volume-group or logical-volume name gets doubled to --, which is a genuine "wait, why are there two dashes" moment the first time you hit it). When you see /dev/mapper/anything, you are looking at a device mapper device, full stop — that directory is dm's public face on the filesystem.

A Real Stacked Example

Here is the layout you'll meet on a great many encrypted servers and laptops, and it shows three dm-related layers (well, two dm plus an md-or-dm RAID) sitting on one physical disk. The job: a disk, encrypted at rest, carved into resizable volumes, each formatted with a filesystem.

physical disk        /dev/sda
   └─ partition       /dev/sda2            (a GPT partition)
        └─ LUKS        /dev/mapper/cryptroot   ← dm-crypt target
             └─ LVM PV → VG "vg0"               ← dm-linear segments
                  ├─ /dev/mapper/vg0-root  → ext4   (mounted at /)
                  ├─ /dev/mapper/vg0-var   → xfs    (mounted at /var)
                  └─ /dev/mapper/vg0-swap  → swap

Trace a single write from the top: an application writes a byte to a file on /. The filesystem (ext4) turns that into a block write to /dev/mapper/vg0-root. That's a dm-linear device, so dm forwards the block — possibly with an offset — to the LUKS device /dev/mapper/cryptroot. That's a dm-crypt device, so dm encrypts the block and forwards it to /dev/sda2, a partition on the physical disk. Three hops, each a device-mapper (or partition) translation, all in the kernel, all invisible to the application — which still thinks it wrote one byte to one disk.

lsblk renders this stack beautifully, which is exactly why it's the first command to reach for:

lsblk

NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                     8:0    0   500G  0 disk
├─sda1                  8:1    0   512M  0 part  /boot/efi
└─sda2                  8:2    0 499.5G  0 part
  └─cryptroot         253:0    0 499.5G  0 crypt
    ├─vg0-root        253:1    0    50G  0 lvm   /
    ├─vg0-var         253:2    0   100G  0 lvm   /var
    └─vg0-swap        253:3    0     8G  0 lvm   [SWAP]

The indentation is the stack, top of the tree being closest to the metal. Note the TYPE column doing the storytelling: disk, then part, then crypt (a dm-crypt device), then three lvm devices. Note too that everything from cryptroot down has major number 253 — that's the device-mapper major on most distributions, a dead giveaway that you're looking at dm devices rather than real hardware. lsblk -f adds the filesystem type and UUID on each leaf if you want the full picture.

How I Inspect It

lsblk gives the view from above. To see the stack the way the kernel sees it — as tables and dependencies — you drop to dmsetup, the low-level dm control tool. My honest workflow: I reach for dmsetup to understand or unstick, almost never to create. Creating dm devices by hand is what cryptsetup and lvcreate are for, and doing it manually is an excellent way to make a mistake the high-level tools would have caught.

The single most useful command is the dependency tree:

dmsetup ls --tree

vg0-root (253:1)
 └─cryptroot (253:0)
    └─ (8:2)
vg0-var (253:2)
 └─cryptroot (253:0)
    └─ (8:2)
cryptroot (253:0)
 └─ (8:2)

This is the dm-native version of the lsblk tree: every mapped device and what it sits on, by major:minor. It instantly answers "why can't I close this LUKS device?" — because vg0-root and vg0-var are stacked on top of it, and you must deactivate them first.

To see the actual table — the routing rule the kernel is running for a device:

dmsetup table cryptroot

0 1047426048 crypt aes-xts-plain64 :64:logon:cryptsetup:...-d0 0 8:2 32768

That one line tells you the cipher (aes-xts-plain64), where the key lives (a kernel keyring reference, not the key itself), the backing device (8:2), and the offset. For a quick health check without the gory args, dmsetup status <name> reports per-target runtime state, and dmsetup info <name> shows the device's open count and whether anything has it held.

Pro Tip

When a disk "won't let go" — wipefs, parted, or mkfs insist the device is busy and you swear nothing is using it — the culprit is almost always a forgotten dm mapping squatting on it. Run dmsetup ls --tree to find the stray device, then remove it from the top down with dmsetup remove <name> (or better, the proper high-level teardown: vgchange -an, cryptsetup close). A dm-linear left behind by an aborted install or a half-finished migration is the classic offender, and it's invisible to every tool that doesn't think to ask device mapper directly.

Cheat Sheet

The high-level tools first (what you'll actually use day to day), then the dm-native commands for when you need to look under the hood.

# --- See the stack (start here) ---
lsblk                                  # the layering tree, hardware at the root
lsblk -f                               # same, with filesystem type + UUID on each leaf
dmsetup ls --tree                      # dm-native dependency tree (who sits on whom)
dmsetup ls                             # flat list of all dm devices + their major:minor

# --- Inspect a specific mapping ---
dmsetup table <name>                   # the routing table (target type + args)
dmsetup status <name>                  # per-target runtime state
dmsetup info <name>                    # open count, read-only flag, UUID

# --- The high-level tools that BUILD dm devices for you ---
cryptsetup luksOpen /dev/sda2 cryptroot   # dm-crypt: decrypt → /dev/mapper/cryptroot
cryptsetup close cryptroot                # tear the dm-crypt device down
vgchange -ay vg0                          # activate LVM volumes (creates dm-linear devices)
vgchange -an vg0                          # deactivate them (removes the dm devices)
multipath -ll                             # show dm-multipath maps and their paths

# --- Low-level teardown (when the high-level tool can't) ---
dmsetup remove <name>                  # remove ONE mapping (must be top of its stack)
dmsetup remove_all                     # nuke all inactive mappings — careful
dmsetup suspend <name> / resume <name> # freeze/thaw I/O (how snapshots get a clean point)

Warning

dmsetup remove and especially dmsetup remove_all operate beneath LVM and cryptsetup, so they can yank a device out from under tools that still think it exists, leaving stale metadata and a confused volume group. Reach for them only to clean up genuine orphans that the high-level teardown (vgchange -an, cryptsetup close) refuses to handle. If the proper tool can do it, let the proper tool do it.

Reading It by Example

A few snapshots and what they tell you at a glance:

/dev/mapper/vg0-data in df output, lvm TYPE in lsblk. Ordinary LVM logical volume — a dm-linear (or dm-stripe) device. Resize it with lvextend + the filesystem's grow command; this is the everyday case.
TYPE crypt in lsblk, a crypt line in dmsetup table. A LUKS / dm-crypt device. The thing mounted is the cleartext view; the ciphertext lives on whatever device sits below it in the tree. Close it with cryptsetup close, not dmsetup remove.
TYPE mpath, names like /dev/mapper/mpatha, multipath -ll shows two paths. dm-multipath. The same SAN LUN reachable over two cables; dm presents one device and fails over silently. An I/O error here may just mean one path died while the other carries on.
A device with major 253 you can't account for, no mountpoint, open count 0 in dmsetup info. A likely orphan — a mapping left behind by an aborted operation. Confirm it's truly unused, then remove it top-down.
/dev/dm-3 appearing in logs or iostat, no friendly name in sight. That's the kernel's internal name for a dm device; cross-reference dmsetup ls (which prints both the name and the 253:N pair) to find out which logical volume or encrypted device it really is.

History and Philosophy

Device mapper arrived in the Linux 2.6 kernel (2003) as the engine beneath LVM2, replacing the older, more monolithic LVM1. The design decision that made it great was refusing to be just a volume manager. Instead of baking volume-management logic into the kernel, the authors — Joe Thornber, Heinz Mauelshagen, and others at Sysenor and later Red Hat — built a generic, minimal block-remapping framework and pushed all the policy out into user space and into pluggable targets. The kernel does the dumb, fast part (route blocks according to a table); user-space tools do the smart, flexible part (decide what the table should be). That separation is why one engine could grow to host encryption, multipath, thin provisioning, caching, and integrity checking without the core ever bloating.

It's a very Unix way to build something. Rather than a dozen special-purpose drivers each reinventing block remapping, there's one small mechanism and a family of targets that compose. The payoff is exactly the composability you saw earlier: because every target produces and consumes the same kind of block device, you can stack them in any sensible order — encryption over RAID over linear, cache over thin over crypt — and each layer neither knows nor cares what the others are doing. The famous storage tools didn't have to coordinate; they only had to agree on the shape of a block device, which the kernel already defined. Good interfaces are the ones that let unrelated people build things that snap together years apart, and dm is a quietly excellent example.

The other thing worth appreciating: dm's restraint. It does nothing clever about what your data means — no filesystem semantics, no idea what a file is. It moves blocks and gets out of the way. All the intelligence lives in the targets and the tools. That minimalism is exactly why it's been load-bearing under so much of Linux storage for two decades without becoming a liability — the best foundations are the ones you forget are there.