27

I cannot figure out the mapping between different logical and physical block device names. The output of "cat /proc/diskstats" is :

 104 0 cciss/c0d0 ... 104 1 cciss/c0d0p1 ... 104 2 cciss/c0d0p2 ... 104 16 cciss/c0d1 ... 253 0 dm-0 ... 253 1 dm-1 ... 253 2 dm-2 ... 253 3 dm-3 ...

The output of "df -h" is :

/dev/cciss/c0d0p1 99M 39M 56M 42% /boot /dev/mapper/VolGroup01-LogVol02 908G 760G 103G 89% /home /dev/mapper/VolGroup01-LogVol03 193G 181G 2.6G 99% /opt /dev/mapper/VolGroup00-LogVol00 54G 11G 41G 21% /

Where do I find the mapping between "cciss" , "dm-#", and "VolGroup##" ?

Thanks

Improve this question
1
  • 3
    Everything in the /dev/mapper directory is typically a symlink to the actual device. Commented Jun 19, 2012 at 1:29

7 Answers 7

Reset to default
31

There're handy dmsetup ls --tree and lsblk utils.

Improve this answer
3
  • 2
    Although that doesn't give you the mapping between VGs and their PVs. For that, you'd need to run pvdisplay and vgdisplay and correlate their output to that of dmsetup ls. Commented Jun 19, 2012 at 9:54
  • 3
    @Alexios, ? Didn't try lsblk? Commented Jun 20, 2012 at 13:17
  • No lsblk on CentOS 5. Commented Sep 25, 2019 at 17:05
7

I was just running into this, so I'll document what helped me here.

poise's answer is correct, You can get all of the information you need from dmsetup ls --tree, if you know how to interpret the output.

cciss is the device name, that's your actual disk. The man page spells it out well, but I'll copy the relevant section here:

 Device nodes The device naming scheme is as follows: Major numbers: 104 cciss0 105 cciss1 106 cciss2 105 cciss3 108 cciss4 109 cciss5 110 cciss6 111 cciss7 Minor numbers: b7 b6 b5 b4 b3 b2 b1 b0 |----+----| |----+----| | | | +-------- Partition ID (0=wholedev, 1-15 partition) | +-------------------- Logical Volume number The device naming scheme is: /dev/cciss/c0d0 Controller 0, disk 0, whole device /dev/cciss/c0d0p1 Controller 0, disk 0, partition 1 /dev/cciss/c0d0p2 Controller 0, disk 0, partition 2 /dev/cciss/c0d0p3 Controller 0, disk 0, partition 3 /dev/cciss/c1d1 Controller 1, disk 1, whole device /dev/cciss/c1d1p1 Controller 1, disk 1, partition 1 /dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 /dev/cciss/c1d1p3 Controller 1, disk 1, partition 3

The "dm-#" is the device mapper number. The easiest way to map DM numbers is to run lvdisplay, which shows the logical volume name, the volume group it belongs to, and the block device. In the "Block device" row, the value listed after the colon is the DM number. 

root@centos:/dev > lvdisplay /dev/vg0/opt --- Logical volume --- LV Name /dev/vg0/opt VG Name vg0 LV UUID ObffAT-txIn-5Rwy-bW5s-gekn-VLZv-71mDZi LV Write Access read/write LV Status available # open 1 LV Size 1.00 GB Current LE 32 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:5

Which maps back nicely to the output of dmsetup ls --tree

vg0-opt (253:5) └─ (104:3)

You can also see the DM number mappings by running ls -lrt /dev/mapper.

root@centos:/dev > ls -lrt /dev/mapper total 0 crw------- 1 root root 10, 60 Aug 29 2013 control brw-rw---- 1 root disk 253, 0 Aug 29 2013 vg0-root brw-rw---- 1 root disk 253, 1 Aug 29 2013 vg0-usr brw-rw---- 1 root disk 253, 2 Aug 29 2013 vg0-tmp brw-rw---- 1 root disk 253, 3 Aug 29 2013 vg0-var brw-rw---- 1 root disk 253, 4 Aug 29 2013 vg0-home brw-rw---- 1 root disk 253, 5 Aug 29 2013 vg0-opt

The sixth column lists the DM number. So, for my server, vg0-opt is mounted on /opt, and maps back to DM-5.

Improve this answer
6

Use dmsetup ls --tree -o blkdevname.

[root@redhat7 Packages]# dmsetup ls --tree -o blkdevname rhel-swap <dm-1> (253:1) └─ <sda2> (8:2) rhel-root <dm-0> (253:0) └─ <sda2> (8:2) oraclevg-oraclelv <dm-2> (253:2) └─ <sdb> (8:16)
Improve this answer
1
  • needs root access Commented Nov 29, 2019 at 19:39
3

Ok, finally figured that out.

pvscan command provides the mapping I'm looking for.

Improve this answer
1
  • pvs, rather, or did I misunderstand the question? Commented Jun 19, 2012 at 23:37
3

@Jon Buys's and @poige's answers are correct, but at least on systems with a relatively recent kernel, it is even simpler.

The entries in /dev/mapper are simply soft links pointing to the dm-x device in /dev, so all you should need is:

ls -l /dev/mapper

For example, on my system, this shows:

# ls -l /dev/mapper/ total 0 crw-------. 1 root root 10, 236 Dec 12 10:11 control lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_cache_pool_home_cdata -> ../dm-3 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_cache_pool_home_cmeta -> ../dm-4 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_cache_pool_var_cdata -> ../dm-7 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_cache_pool_var_cmeta -> ../dm-8 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_home -> ../dm-6 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_home_corig -> ../dm-5 lrwxrwxrwx. 1 root root 8 Dec 12 10:11 vg_raid10-lv_var -> ../dm-10 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_raid10-lv_var_corig -> ../dm-9 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_ssd-lv_root -> ../dm-0 lrwxrwxrwx. 1 root root 7 Dec 12 10:11 vg_ssd-lv_swap -> ../dm-1 lrwxrwxrwx. 1 root root 8 Dec 27 20:00 vg_ssd_sata-docker--pool -> ../dm-13 lrwxrwxrwx. 1 root root 8 Dec 27 20:00 vg_ssd_sata-docker--pool_tdata -> ../dm-12 lrwxrwxrwx. 1 root root 8 Dec 27 20:00 vg_ssd_sata-docker--pool_tmeta -> ../dm-11 lrwxrwxrwx. 1 root root 7 Dec 27 20:00 vg_ssd_sata-lv_scratch -> ../dm-2 lrwxrwxrwx. 1 root root 8 Dec 27 20:00 vg_ssd_sata-lv_vms -> ../dm-14

If your ls is unhelpful and does not show the soft links, try this:

for x in /dev/mapper/*; do echo "$(realpath $x) -> $x"; done;

which should output something like:

/dev/mapper/control -> /dev/mapper/control /dev/dm-3 -> /dev/mapper/vg_raid10-lv_cache_pool_home_cdata /dev/dm-4 -> /dev/mapper/vg_raid10-lv_cache_pool_home_cmeta ...

and if you want to find a specific mapping e.g. dm-6:

# (for x in /dev/mapper/*; do echo "$(realpath $x) -> $x"; done;) | grep dm-6 /dev/dm-6 -> /dev/mapper/vg_raid10-lv_home
Improve this answer
1

I've had the same issue, maybe little "deeper": up to the mount point level. In case anyone is interested, here are two functions I'm using, for querying both ways.

######## FIND THE LVPATH of an existing FS. Query the lvm using FS' mount point fileSystem_to_lvPath(){ FS_TO_QUERY=$1 #Call like this: $0 /tmp #Relevant commands for debug: blkid, lsblk, dmsetup, lvdisplay, lvs #OLD Solution: DEV_MAPPER=$(df -l --output=source $1 | awk '{print $1}' | cut -d"/" -f 4 | tail -1) #Find DeviceMapper_MajorMinorNumber for specific fs DeviceMapper_MajorMinorNumber=$(lsblk --noheadings --output TYPE,MAJ:MIN,MOUNTPOINT | grep -w lvm | grep -w $FS_TO_QUERY | awk '{print $2}') #VG=$(lvs --noheadings --separator : --options lv_kernel_major,lv_kernel_minor,vg_name,lv_name,lv_path | grep $DeviceMapper_MajorMinorNumber | awk -F : '{print $3}') #LV=$(lvs --noheadings --separator : --options lv_kernel_major,lv_kernel_minor,vg_name,lv_name,lv_path | grep $DeviceMapper_MajorMinorNumber | awk -F : '{print $4}') LV_PATH=$(lvs --noheadings --separator : --options lv_kernel_major,lv_kernel_minor,vg_name,lv_name,lv_path | grep $DeviceMapper_MajorMinorNumber | awk -F : '{print $5}') echo $LV_PATH #echo "$VG/$LV" }

and the reverse query:

######## FIND THE FS (and FS' mountpoint) of an existing LVPATH: lvPath_to_fileSystem(){ LV_PATH=$1 #Call like this: $0 /dev/vg00/opt #Relevant commands for debug: blkid, lsblk, dmsetup, lvdisplay, lvs #OLD Solution: DEV_MAPPER=$(df -l --output=source $1 | awk '{print $1}' | cut -d"/" -f 4 | tail -1) #Find DeviceMapper_MajorMinorNumber for specific lv_path DeviceMapper_MajorMinorNumber=$(lvs --noheadings --separator : --options lv_kernel_major,lv_kernel_minor,vg_name,lv_name,lv_path | grep $LV_PATH | awk -F : '{print $1":"$2}') FS=$(lsblk --noheadings --output TYPE,MAJ:MIN,MOUNTPOINT | grep -w lvm | grep -w $DeviceMapper_MajorMinorNumber | awk '{print $3}') echo $FS }
Improve this answer
-2

All binding are mapped in file /etc/multipath/bindings. You can rename here any device like from /dev/mapper/mpathf to /dev/mapper/mpathe.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.