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 1461993 - RFE - Log creation and removal of dm devices
Summary: RFE - Log creation and removal of dm devices
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.4
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Heinz Mauelshagen
QA Contact: Storage QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-15 20:49 UTC by John Pittman
Modified: 2021-09-06 12:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-13 14:59:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
example patch to add dm creation/removal logging (665 bytes, patch)
2017-06-15 20:49 UTC, John Pittman 		no flags Details | Diff
View All

Description John Pittman 2017-06-15 20:49:12 UTC 
Created attachment 1288202 [details]
example patch to add dm creation/removal logging

Description of problem:

RFE proposal to log addition and removal of dm devices by default.  Thought of this while troubleshooting an environment in which I needed to know if a multipath partition device was created during a particular boot process.  Then realized that there is no record of dm device creation.  This is inconsistent with other devices, as their creation is logged (dm, mdadm, multipath, lvm activation).  Very rarely are there systems that do not have an active dm layer.

Even though the names are not persistent, troubleshooting information can be gathered from knowing when the dm layer is increased or reduced.  Adding the actual dmsetup name to the output would be wonderful, but unsure if this is possible; I could not find an easy way.

Version-Release number of selected component (if applicable):

kernel-3.10.0-681.el7

Actual results:

dm-x device addition and removal is not logged

Expected results:

Jun 15 16:27:26 localhost.localdomain kernel: device-mapper: core: Created dm-0
Jun 15 16:27:26 localhost.localdomain kernel: device-mapper: core: Created dm-1
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-2
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-3
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Created dm-4
Jun 15 16:27:28 localhost.localdomain kernel: device-mapper: core: Removing dm-4
Jun 15 16:27:29 localhost.localdomain kernel: device-mapper: core: Created dm-4
Jun 15 16:27:29 localhost.localdomain kernel: device-mapper: core: Created dm-5
......
Jun 15 16:31:57 localhost.localdomain kernel: device-mapper: core: Removing dm-4

Any consideration is appreciated.
Comment 2 John Pittman 2017-06-15 20:56:15 UTC 
Meant to mention we log sd layer attach/creation as well, so logging dm would line up with that layer too.
Comment 3 Zdenek Kabelac 2017-06-16 07:43:32 UTC 
Don't you rather want to see logging of 'lvm2' messages ?

Such feature already exists in lvm.conf.

See the lvm.conf   'syslog=1'  setting for logging in log{}  section.

You may also select your preferred 'verbosity' level for less or more detailed syslogging of any lvm2 command.


What'd be the purpose of  'dm-XX' logging - these numbers are rather meaningless - as it's quite hard to 'map'  dm-X  to i.e. VG/LV  in system for just this 'trace'.
Comment 4 Milan Broz 2017-06-16 07:59:20 UTC 
I do not think that all dm devices creation and removal should be logged by default.

Note, there is difference between plugging of hw device (sd layer) and creating virtual (and possible private) device mapping.

For example, cryptsetup in some situations uses temporary devices that maps keyslots. This action is private to cryptsetup and should be visible only if users explicitly switch debug on. (It could reveal which keyslot was used, how many tries user did etc).

And if you are using hidden disk mapping for Truecrypt compatible device, it is even security problem for the user (it documents that user mapped something that should be, well, "hidden".
There are probably other info that already reveals such action in log but we should not make this even worse.

Please be very careful with enabling such features. For lvm it maybe makes sense (but just for top-level device and not with dm-X name) but for other users of device-mapper subsystem is is not so great idea.
Comment 5 John Pittman 2017-06-16 12:35:33 UTC 
Milan, Zdenek,
Yes, I agree.  My need was related to wanting to see multipath partition devices being created.  Perhaps I can focus my efforts there and see if I can come up with a better solution.  Will close this or change component with updated possible patch as soon as I'm able to research this more.

Thanks for your time.
Comment 6 John Pittman 2017-10-12 15:11:40 UTC 
Sorry guys, I forgot about this.  I am fine if this is closed.  The premise is good for troubleshooting rare conditions, but that's about it I think.
Comment 7 Mark Thacker 2017-10-13 14:59:37 UTC 
Going to close this as alternatives were suggested.
Note You need to log in before you can comment on or make changes to this bug.