In looking through the sosreports, I think it would be helpful to add "dmsetup ls --tree" to the commands we run. Although the info is available with other existing dmsetup commands, it is an excellent way to get a summary of complex setups. Here's an example of an LVM mirror, with mirror images on partitions created on top of multipath devices. The multipath devices are on simple block devices. As you can see, it is easy to see the stacking from the "dmsetup ls --tree" output: # dmsetup ls --tree vgmpathtest-lvmpathmir (253:14) ├─vgmpathtest-lvmpathmir_mimage_1 (253:13) │ └─mpath5p1 (253:5) │ └─mpath5 (253:2) │ ├─ (8:16) │ └─ (8:0) ├─vgmpathtest-lvmpathmir_mimage_0 (253:12) │ └─mpath6p1 (253:6) │ └─mpath6 (253:3) │ ├─ (8:48) │ └─ (8:32) └─vgmpathtest-lvmpathmir_mlog (253:11) └─mpath7 (253:4) ├─ (8:80) └─ (8:64) VolGroup00-LogVol01 (253:1) └─ (202:2) vgtest-lvmir (253:10) ├─vgtest-lvmir_mimage_1 (253:9) │ └─ (7:1) ├─vgtest-lvmir_mimage_0 (253:8) │ └─ (7:0) └─vgtest-lvmir_mlog (253:7) └─ (7:3) VolGroup00-LogVol00 (253:0) └─ (202:2) But it is much harder to see the stacking with what is there today in sos - the output from "dmsetup info", "dmsetup status", and "dmsetup table". We could piece together the stacking from "dmsetup table" but it requires further processing (take output from "dmsetup info to get map name to major/minor, then parse "dmsetup table", etc): # dmsetup table mpath5p1: 0 188731557 linear 253:2 63 mpath6p1: 0 3328769 linear 253:3 1 vgmpathtest-lvmpathmir: 0 8192 mirror disk 3 253:11 1024 block_on_error 2 253:12 0 253:13 0 vgtest-lvmir_mimage_1: 0 24576 linear 7:1 384 vgtest-lvmir_mimage_0: 0 24576 linear 7:0 384 vgmpathtest-lvmpathmir_mlog: 0 8192 linear 253:4 384 mpath7: 0 20971520 multipath 1 queue_if_no_path 0 1 1 round-robin 0 2 1 8:64 128 8:80 128 mpath6: 0 209715200 multipath 1 queue_if_no_path 0 1 1 round-robin 0 2 1 8:32 128 8:48 128 vgmpathtest-lvmpathmir_mimage_1: 0 8192 linear 253:5 384 VolGroup00-LogVol01: 0 2162688 linear 202:2 9896320 vgtest-lvmir_mlog: 0 8192 linear 7:3 384 mpath5: 0 188743680 multipath 1 queue_if_no_path 0 1 1 round-robin 0 2 1 8:0 128 8:16 128 vgmpathtest-lvmpathmir_mimage_0: 0 8192 linear 253:6 384 vgtest-lvmir: 0 24576 mirror disk 3 253:7 1024 block_on_error 2 253:8 0 253:9 0 VolGroup00-LogVol00: 0 9895936 linear 202:2 384 # dmsetup info -c Name Maj Min Stat Open Targ Event UUID mpath5p1 253 5 L--w 1 1 0 part1-mpath-360a980006e424b626d34613047437766 mpath6p1 253 6 L--w 1 1 0 part1-mpath-360a980006e424b626d34613047447078 vgmpathtest-lvmpathmir 253 14 L--w 0 1 1 LVM-rNO5kEQCdfoUfpsFXIguleIF0o6PPu1MEuHA9ADD5dtr1kLTVRBZHhojFfJHmZul vgtest-lvmir_mimage_1 253 9 L--w 1 1 0 LVM-ROXcWNEt1MK767i4QdV09EeHTAZrDDzX2OfO6aPv5wcTpD63a8RIjRiuMJkJOiQl vgtest-lvmir_mimage_0 253 8 L--w 1 1 0 LVM-ROXcWNEt1MK767i4QdV09EeHTAZrDDzX2vnjsbnbu75wW6WciLbpYaGCdndR87Vt vgmpathtest-lvmpathmir_mlog 253 11 L--w 1 1 0 LVM-rNO5kEQCdfoUfpsFXIguleIF0o6PPu1MupiMHiphrhRdgTYGflsKHiwKE71QHb40 mpath7 253 4 L--w 1 1 0 mpath-360a980006e424b626d34614b79707454 mpath6 253 3 L--w 1 1 0 mpath-360a980006e424b626d34613047447078 vgmpathtest-lvmpathmir_mimage_1 253 13 L--w 1 1 0 LVM-rNO5kEQCdfoUfpsFXIguleIF0o6PPu1MElzffHWferZ5Kb4ooBAmM6vE0xhcQkFz VolGroup00-LogVol01 253 1 L--w 1 1 0 LVM-fCGl4gutrN5reXkPYS9JA1FWtML6Yra8UrrjM6GWF92jZPlQ9vIwOauAAZgyZK4e vgtest-lvmir_mlog 253 7 L--w 1 1 0 LVM-ROXcWNEt1MK767i4QdV09EeHTAZrDDzX7vzVcxdky4dpJLeW8sR74wtmGPI2fMQq mpath5 253 2 L--w 1 1 0 mpath-360a980006e424b626d34613047437766 vgmpathtest-lvmpathmir_mimage_0 253 12 L--w 1 1 0 LVM-rNO5kEQCdfoUfpsFXIguleIF0o6PPu1MGlTprEAoONIpMzzTiug5XaPnlrMFowYx vgtest-lvmir 253 10 L--w 0 1 1 LVM-ROXcWNEt1MK767i4QdV09EeHTAZrDDzXQhCKjGKnr2XSlplayeSSdziSAB3zrAB3 VolGroup00-LogVol00 253 0 L--w 1 1 0 LVM-fCGl4gutrN5reXkPYS9JA1FWtML6Yra8cE4dd5B6091CiMG2mCTywmo9gsYbVR14
Created attachment 476421 [details] One line simple patch which adds "dmsetup ls --tree"
I've added "dmsetup ls --tree" to lvmdump command upstream in lvm2 project. Should be in lvm2 release 2.02.83.
Upstream through https://fedorahosted.org/sos/changeset/1079
Not in rawhide build from what I can tell, so marking as post.
Checked this mirror: http://archive.linux.duke.edu/pub/fedora/linux/development/rawhide/x86_64/os/Packages/ Contains this build: http://archive.linux.duke.edu/pub/fedora/linux/development/rawhide/x86_64/os/Packages/sos-2.2-2.fc15.noarch.rpm
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This has been fixed for some time now. # more /etc/redhat-release Fedora release 18 (Spherical Cow) # rpm -qf `which sosreport` sos-2.2-30.fc18.noarch # more rdu-esx-dwysocha-f18-node1-2013091909001379595649/sos_commands/devicemapper/dmsetup_ls_--tree fedora-swap (253:0) └─ (8:2) fedora-root (253:1) └─ (8:2)