RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 731785 - RFE: add option to dmsetup to display device names for "dmsetup deps"
Summary: RFE: add option to dmsetup to display device names for "dmsetup deps"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Peter Rajnoha
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 756082
TreeView+ depends on / blocked
 
Reported: 2011-08-18 16:28 UTC by Dave Wysochanski
Modified: 2018-11-29 21:48 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.02.95-1.el6
Doc Type: Enhancement
Doc Text:
The dmsetup command now supports displaying block device names for any devices listed on deps, ls and info command output. For dmsetup 'deps' and 'ls' command, it's possible to switch among 'devno' (major and minor number, the default and the original behaviour), 'devname' (mapping name for a device-mapper device, block device name otherwise) and 'blkdevname' (always display a block device name). For dmsetup 'info' command, it's possible to use new 'blkdevname' and 'blkdevs_used' fields.
Clone Of:
Environment:
Last Closed: 2012-06-20 14:52:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0962 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2012-06-19 21:12:11 UTC

Description Dave Wysochanski 2011-08-18 16:28:52 UTC
dmsetup deps should allow display of sd device name instead of (major,minor) pairs.
Example:
dmsetup deps mpathf
2 dependencies  : (8, 112) (65, 16)

desired output
2 dependencies  : (sdh) (sdr)

It's understandable that the major,minor pairs are displayed, since dmsetup is dumping kernel information, and device names are only known in userspace.  However, this should be achievable by adding the following to dmsetup:
1) an sane command option to dmsetup to display device names
2) a method for mapping a major/minor pair to userspace visible device name, such as sysfs lookup or /proc/partitions

Details of the request

dmsetup uses device names instead of (maj,min) numbers

    What is the nature and description of the request?

Using major minor numbers for everything can be very confusing. It requires you to cross reference everything by doing a ls -l /dev every time you want to relate dmsetup to another utility, for example, iostat.

    Why does the customer need this? (List the business requirements here)

To save time and make the lives of the systems/storage administrators easier.

    How would the customer like to achieve this? (List the functional
    requirements here)

Have dmsetup look the name up, and then put that out instead of maj,min. May require a new flag for compatbility 

    For each functional requirement listed in question 4, specify how Red Hat
    and the customer can test to confirm the requirement is successfully
    implemented.

1) dmsetup deps mpathf
2) output shows device name and not (maj,min)

    Is there already an existing RFE upstream or in Red Hat bugzilla?

Not that I could find:
https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=device-mapper-multipath&product=Red%20Hat%20Enterprise%20Linux%206&classification=Red%20Hat

    How quickly does this need resolved? (desired target release)

minor

    Does this request meet the RHEL Bug and Feature Inclusion Criteria
    (please review)
yes

    List the affected packages

device-mapper device-mapper-multipath

    Would the customer be able to assist in testing this functionality if
    implemented?

yes

Comment 1 Milan Broz 2011-08-18 17:07:32 UTC
It would be nice, but please note I had RFE for lsblk which provide exactly these simple listings based on sysfs (over all storage devices, not only DM):

# lsblk /dev/sda
NAME                     MAJ:MIN RM   SIZE RO MOUNTPOINT
sda                        8:0    0  68.4G  0 
├─sda1                     8:1    0 196.1M  0 /boot
├─sda2                     8:2    0 996.2M  0 [SWAP]
├─sda3                     8:3    0  33.6G  0 
└─sda4                     8:4    0  33.6G  0 
  └─vg_rhel6-root (dm-0) 253:0    0  33.6G  0 /

Do they know about it? (it is in released version already.)

Comment 2 Bryn M. Reeves 2011-08-18 17:16:23 UTC
For scripts it's also often easier to follow the deps directly in sysfs via the symlinks in the /sys/block/<device>/slaves directory.

Comment 3 James M. Leddy 2011-08-19 12:24:37 UTC
(In reply to comment #1)
> It would be nice, but please note I had RFE for lsblk which provide exactly
> these simple listings based on sysfs (over all storage devices, not only DM):
> 
> # lsblk /dev/sda
> NAME                     MAJ:MIN RM   SIZE RO MOUNTPOINT
> sda                        8:0    0  68.4G  0 
> ├─sda1                     8:1    0 196.1M  0 /boot
> ├─sda2                     8:2    0 996.2M  0 [SWAP]
> ├─sda3                     8:3    0  33.6G  0 
> └─sda4                     8:4    0  33.6G  0 
>   └─vg_rhel6-root (dm-0) 253:0    0  33.6G  0 /
> 
> Do they know about it? (it is in released version already.)

You could either do a ls -l or use lsblk, but this still requires two steps. dmsetup, then lsblk. It would be more convenient if it was just dmsetup and that made sense of everything.

Also, all of these solutions are a devname -> maj,min mapping, as far as I know there isn't a way to get maj:min -> devname mapping.

Comment 4 Milan Broz 2011-08-19 12:38:16 UTC
Perhaphs not exactly what you want, but:

for DM: cat /sys/dev/block/$MAJOR:$MINOR/dm/name

dmsetup deps -j $MAJOR -m $MINOR

(hm, and lsblk has no such option, seems like a bug:-)
or maybe
lsblk /dev/block/$MAJOR:$MINOR

Comment 7 Peter Rajnoha 2012-01-11 13:13:14 UTC
After a review and further discussion, the final output is as follows (an example with one linear [lvol0] and one mirror [lvol1] LVM2 volume):


------------------
dmsetup info -c -o
------------------        
[0] rawhide/~ # dmsetup info -c -o name,blkdevname,devnos_used,blkdevs_used
Name              BlkDevName       DevNos            BlkDevNames     
vg-lvol1          dm-4             253:3,253:2,253:1 dm-3,dm-2,dm-1  
vg-lvol1_mimage_1 dm-3             8:80              sdf             
vg-lvol0          dm-0             8:64              sde             
vg-lvol1_mimage_0 dm-2             8:64              sde             
vg-lvol1_mlog     dm-1             8:128             sdi 


------------
dmsetup deps
------------
[0] rawhide/~ # dmsetup deps
vg-lvol1: 3 dependencies	: (253, 3) (253, 2) (253, 1)
vg-lvol1_mimage_1: 1 dependencies	: (8, 80)
vg-lvol0: 1 dependencies	: (8, 64)
vg-lvol1_mimage_0: 1 dependencies	: (8, 64)
vg-lvol1_mlog: 1 dependencies	: (8, 128)

[0] rawhide/~ # dmsetup deps -o devno
vg-lvol1: 3 dependencies	: (253, 3) (253, 2) (253, 1)
vg-lvol1_mimage_1: 1 dependencies	: (8, 80)
vg-lvol0: 1 dependencies	: (8, 64)
vg-lvol1_mimage_0: 1 dependencies	: (8, 64)
vg-lvol1_mlog: 1 dependencies	: (8, 128)

[0] rawhide/~ # dmsetup deps -o blkdevname
vg-lvol1: 3 dependencies	: (dm-3) (dm-2) (dm-1)
vg-lvol1_mimage_1: 1 dependencies	: (sdf)
vg-lvol0: 1 dependencies	: (sde)
vg-lvol1_mimage_0: 1 dependencies	: (sde)
vg-lvol1_mlog: 1 dependencies	: (sdi)

[0] rawhide/~ # dmsetup deps -o devname   
vg-lvol1: 3 dependencies	: (vg-lvol1_mimage_1) (vg-lvol1_mimage_0) (vg-lvol1_mlog)
vg-lvol1_mimage_1: 1 dependencies	: (sdf)
vg-lvol0: 1 dependencies	: (sde)
vg-lvol1_mimage_0: 1 dependencies	: (sde)
vg-lvol1_mlog: 1 dependencies	: (sdi)

[0] rawhide/~ # dmsetup deps -o abc
Option not recognised: abc
Couldn't process command line.


----------
dmsetup ls
----------
[0] rawhide/~ # dmsetup ls
vg-lvol1	(253:4)
vg-lvol1_mimage_1	(253:3)
vg-lvol0	(253:0)
vg-lvol1_mimage_0	(253:2)
vg-lvol1_mlog	(253:1)

[0] rawhide/~ # dmsetup ls -o devno
vg-lvol1	(253:4)
vg-lvol1_mimage_1	(253:3)
vg-lvol0	(253:0)
vg-lvol1_mimage_0	(253:2)
vg-lvol1_mlog	(253:1)

[0] rawhide/~ # dmsetup ls -o devname
vg-lvol1	(vg-lvol1)
vg-lvol1_mimage_1	(vg-lvol1_mimage_1)
vg-lvol0	(vg-lvol0)
vg-lvol1_mimage_0	(vg-lvol1_mimage_0)
vg-lvol1_mlog	(vg-lvol1_mlog)

[0] rawhide/~ # dmsetup ls -o blkdevname
vg-lvol1	(dm-4)
vg-lvol1_mimage_1	(dm-3)
vg-lvol0	(dm-0)
vg-lvol1_mimage_0	(dm-2)
vg-lvol1_mlog	(dm-1)

[0] rawhide/~ # dmsetup ls -o abc
Option not recognised: abc
Couldn't process command line.


-----------------
dmsetup ls --tree
-----------------
[0] rawhide/~ # dmsetup ls --tree
vg-lvol1 (253:4)
 |-vg-lvol1_mimage_1 (253:3)
 |  `- (8:80)
 |-vg-lvol1_mimage_0 (253:2)
 |  `- (8:64)
 `-vg-lvol1_mlog (253:1)
    `- (8:128)
vg-lvol0 (253:0)
 `- (8:64)

[0] rawhide/~ # dmsetup ls --tree -o blkdevname
vg-lvol1 <dm-4> (253:4)
 |-vg-lvol1_mimage_1 <dm-3> (253:3)
 |  `- <sdf> (8:80)
 |-vg-lvol1_mimage_0 <dm-2> (253:2)
 |  `- <sde> (8:64)
 `-vg-lvol1_mlog <dm-1> (253:1)
    `- <sdi> (8:128)
vg-lvol0 <dm-0> (253:0)
 `- <sde> (8:64)

[0] rawhide/~ # dmsetup ls --tree -o abc
Tree options not recognised: abc
Couldn't process command line.

--------------------------------------------------------------

Briefly:

 * devno == major and minor pair
   blkdevname == kernel (block device) name (e.g. dm-0, sda, md0, ...)
   devname == map name for dm devices (the one found in /dev/mapper dir), equal to blkdevname for non-dm devices

 * new '-o' switch with possible options of '{devno|blkdevname|devname}' for dmsetup deps and ls

 * new '-o blkdevname' option for dmsetup ls --tree (ls --tree already had the '-o' switch so this is just an addition of a new option for completeness and consistency with other commmands)

 * new '-c -o blkdevname,blkdevs_used' options for dmsetup info -c -o


Notice: 'devname' works only with kernels >= 2.6.29 (it reads /sys/dev/block/major:minor/dm/name content). For olders kernels, the 'devname' is equal to 'blkdevname'.

Comment 8 Peter Rajnoha 2012-01-11 13:14:45 UTC
upstream lvm2 v2.02.89/libdevmapper 1.02.68

Comment 12 Peter Rajnoha 2012-04-24 08:29:57 UTC
I've renamed the headers to make it more comprehensible:

  DevNames --> DevNamesUsed
  BlkDevNames --> BlkDevNamesUsed
  DevNos --> DevNosUsed

So we have:

[0] devel/~ # dmsetup info -c -o name,blkdevname,devs_used,devnos_used,blkdevs_used

Name           BlkDevName       DevNamesUsed     DevNosUsed       BlkDevNamesUsed 
c              dm-2             b,a              253:1,253:0      dm-1,dm-0       
b              dm-1                              8:16             sdb             
a              dm-0                              8:0              sda             


It's just a header rename, so it should not cause any harm (scripts use --noheadings anyway).

Comment 15 Peter Rajnoha 2012-04-24 14:08:25 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The dmsetup command now supports displaying block device names for any devices listed on deps, ls and info command output.

For dmsetup 'deps' and 'ls' command, it's possible to switch among 'devno' (major and minor number, the default and the original behaviour), 'devname' (mapping name for a device-mapper device, block device name otherwise) and 'blkdevname' (always display a block device name).

For dmsetup 'info' command, it's possible to use new 'blkdevname' and 'blkdevs_used' fields.

Comment 16 Peter Rajnoha 2012-04-25 10:46:49 UTC
(In reply to comment #12)
> I've renamed the headers to make it more comprehensible:
> 
>   DevNames --> DevNamesUsed
>   BlkDevNames --> BlkDevNamesUsed
>   DevNos --> DevNosUsed

Renamed in lvm2-2.02.95-6.el6.

Comment 18 errata-xmlrpc 2012-06-20 14:52:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0962.html


Note You need to log in before you can comment on or make changes to this bug.