Inspect and Safely Test Device-Mapper Mappings with dmsetup

You will use dmsetup to inspect device-mapper devices, read the table behind a mapping, and create a disposable zero-backed mapping for a syntax and udev smoke test. Allow 15 minutes for inspection, or longer if you need to identify a production device before changing anything. The test mapping below does not write to a disk, but creating and removing any device-mapper node still requires care.

Prerequisites: the dmsetup package, a shell, and root access for commands that talk to the device-mapper kernel driver. The examples use the installed Ubuntu package dmsetup 2:1.02.185-3ubuntu3.2 and libdevmapper 1.02.185, reported by dmsetup --version. The manpage documents the command interface; target availability is a property of the running kernel.

1. Check the installed command

Start with read-only checks. They do not create a mapping or change a table:

$ command -v dmsetup
/usr/sbin/dmsetup
$ dmsetup --version
Library version:   1.02.185 (2022-05-18)

Your path and version may differ. dmsetup --version also tries to report the kernel driver version. If it says that /dev/mapper/control cannot be opened, you are missing access to the driver in this shell or container. Do not interpret that as evidence that all mappings are absent. Retry from a host with the device-mapper control node and suitable privileges.

2. List maps and inspect their state

List the names and device numbers known to device-mapper. Add sudo if the host requires it:

$ sudo dmsetup ls
system-root	253:0
system-swap	253:1

The names above are examples, not expected devices. An empty result can be correct. To see state, tables and identifiers for a named map, run:

$ sudo dmsetup info system-root
Name:              system-root
State:             ACTIVE
Tables present:    LIVE
Open reference count: 1
Event nr:          0
Major, minor:      253, 0
Number of targets: 1
UUID:              LVM-...

Formatting and values depend on the device and package build. For scripts, column output is easier to select:

$ sudo dmsetup info -c -o name,major,minor,attr,open,segments,events,uuid
Name             Maj Min Attr       Open Segments Events UUID
system-root      253   0 L--w         1        1      0 LVM-...

Do not paste a production UUID into a command when a name is sufficient. Names and UUIDs identify kernel mappings, not necessarily the filesystem or mount you intended.

3. Read dependencies and the live table

Before suspending, reloading or removing a map, inspect what it references:

$ sudo dmsetup deps system-root
1 dependencies:
unknown device

The dependency line is host-specific. The deps command can report device numbers, block-device names or map names with -o devno, -o blkdevname or -o devname. To see the table that can be fed back to create or load, use:

$ sudo dmsetup table system-root
0 2097152 linear 8:1 2048

Never treat an unfamiliar table as harmless. A linear target maps sectors to another block device, while crypt, thin, snapshot, mirror and multipath have different arguments and failure modes. The table command suppresses real encryption keys for crypt and integrity targets unless --showkeys is supplied. Avoid that option in copied diagnostics.

4. Check targets before designing a table

Target names are supplied by the kernel, so check them rather than assuming a target is loaded:

$ sudo dmsetup targets
linear           v1.6.0
error            v1.5.0
zero             v1.1.0

Versions and the list vary. The simple zero target returns zeroes on reads and discards writes. That makes it useful for a disposable mapping, but it is not storage and it should never be used where data must persist.

5. Create a disposable zero mapping

The table format is logical-start-sector sector-count target-type target-arguments. This example creates 1,024 sectors, which is 512 KiB, backed by the zero target:

$ sudo dmsetup create dmsetup-demo --table '0 1024 zero'
$ sudo dmsetup info dmsetup-demo
Name:              dmsetup-demo
State:             ACTIVE
Tables present:    LIVE
Number of targets: 1

On a successful create, the live device normally appears as /dev/mapper/dmsetup-demo. The exact info fields vary, so verify the node and table directly:

$ test -b /dev/mapper/dmsetup-demo && echo mapper-node-present
mapper-node-present
$ sudo dmsetup table dmsetup-demo
0 1024 zero

If udev has not caught up, sudo dmsetup mknodes dmsetup-demo asks for the node to be corrected. If the node still does not appear, use the map through dmsetup only and investigate udev before placing it in a service or mount.

6. Remove the test mapping

Remove the demo as soon as the test is complete. This does not erase disk data because the mapping has no backing disk, but it does make the device unavailable:

$ sudo dmsetup remove dmsetup-demo
$ sudo dmsetup info dmsetup-demo
Device does not exist.

If removal reports that the device is open, find and stop the process holding it before retrying. --deferred schedules removal after the last user closes it. That can be useful for a known disposable map, but it can also hide a lingering consumer. Do not use --force casually: for an open device it replaces the table with one that fails all I/O.

There is no safe general-purpose undo for remove. For a mapping backed by real storage, preserve the original table with dmsetup table NAME > NAME.table before a planned change, and follow the storage stack's documented reload and resume procedure. Do not reload a production table from an unreviewed file.

7. Avoid the commands that stop I/O

suspend postpones further I/O and normally synchronises a filesystem first. resume makes an inactive table live. load and reload place a table in the inactive slot; they do not by themselves make it live. These commands belong in a controlled maintenance procedure with an identified filesystem, application and rollback plan.

remove_all attempts to reset every device definition, and wipe_table replaces a table with one that fails new I/O. Both can disrupt unrelated users. Treat --force, --yes, --noflush and --nolockfs as explicit risk decisions, not convenient defaults. Ordinary listing and inspection do not need them.