Figuring out linux’s device mapper

Device mapper does a great job at translating devices to somewhat human readable format.  Yet, that layer breaks down in the logging.  Let’s take the situation where you have an error in the filesystem that is getting reported in dmesg or syslog:

[1297912.800024] EXT4-fs (dm-1): error count: 1
[1297912.800030] EXT4-fs (dm-1): initial error at 1322435090: ext4_find_entry:934: inode 7340671
[1297912.800034] EXT4-fs (dm-1): last error at 1322435090: ext4_find_entry:934: inode 7340671

Questions abound: “This looks bad, but what is this?” “It’s a filesystem problem, but which filesystem?”

Take a look at /dev/dm*:

~]# ls -l /dev/dm*
brw-rw---- 1 root disk 253, 0 Jan 27 14:29 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jan 27 14:29 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jan 27 14:29 /dev/dm-2
brw-rw---- 1 root disk 253, 3 Jan 27 14:29 /dev/dm-3

Then take a look at the results of “dmsetup ls”:

~]# dmsetup ls
VolumeGroupA-Storage        (253, 3)
VolumeGroupB-Stuff       (253, 2)
vg_hostname-lv_swap      (253, 0)
vg_hostname-lv_root      (253, 1)

And, finally, map the two based upon the node number. In the above example, from our ls we know that dm-1 is “253,1” and from dmsetup we know that “253,1” is vg_hostname-lv_root. So, dm-1 is vg_hostname-lv_root, and, since it is the root volume, a forced recheck of the root volume needs to be perfored at the next reboot (touch /forcecheck; init 6). It is best to monitor that re-check of the filesystem, so it would not be advisable to do this fsck remotely.