Bug 1461993 - RFE - Log creation and removal of dm devices
RFE - Log creation and removal of dm devices
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel (Show other bugs)
7.4
x86_64 Linux
unspecified Severity low
: rc
: ---
Assigned To: Heinz Mauelshagen
Storage QE
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-15 16:49 EDT by John Pittman
Modified: 2017-10-13 10:59 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-13 10:59:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description John Pittman 2017-06-15 16:49:12 EDT
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 16:56:15 EDT
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 03:43:32 EDT
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 03:59:20 EDT
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 08:35:33 EDT
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 11:11:40 EDT
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 10:59:37 EDT
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.