Bug 883416 - Need a way to easily fallback to non-udev operation in libdevmapper/lvm2
Need a way to easily fallback to non-udev operation in libdevmapper/lvm2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.4
x86_64 Linux
urgent Severity urgent
: rc
: ---
Assigned To: Peter Rajnoha
Cluster QE
: Regression
Depends On:
Blocks: 880040
  Show dependency treegraph
 
Reported: 2012-12-04 09:53 EST by Peter Rajnoha
Modified: 2013-02-21 03:15 EST (History)
19 users (show)

See Also:
Fixed In Version: lvm2-2.02.98-4.el6
Doc Type: Enhancement
Doc Text:
Feature: Recognize DM_DISABLE_UDEV environment variable while using LVM2 tools, dmsetup and libdevmapper to fallback to non-udev operation fully. Setting this variable acts as a shortcut for using --noudevsync, --noudevrules and --verifyudev option in dmsetup and setting devices/obtain_device_list_from_udev=0, activation/udev_sync=0 (or --noudevsync LVM2 command line option), activation/udev_rules=0 and activation/verify_udev_operations=1 option in LVM2. Changes also apply for any libdevmapper users. Reason: Setting the DM_DISABLE_UDEV environment variable provides a more convenient way of disabling udev support in libdevmapper, dmsetup and LVM2 tools globally without a need to modify any existing configuration settings. This is mostly useful if the system environment does not use udev. Result (if any): Refer to dmsetup manual page and LVM2 manual pages as well as the comments in lvm.conf itself and descriptions of the options mentioned above.
Story Points: ---
Clone Of: 880040
Environment:
Last Closed: 2013-02-21 03:15:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Rajnoha 2012-12-04 09:53:02 EST
Add the DM_DISABLE_UDEV env var instead of setting various options directly.  The DM_DISABLE_UDEV env var gets top priority over all existing settings.
Comment 2 Peter Rajnoha 2012-12-04 10:22:30 EST
To QA:

To test this, use the DM_DISABLE_UDEV=1 environment variable and then try to create/remove dm/lvm devices. This should have the same effect as setting/using:

For dmsetup:
  --noudevsync in dmsetup
  --noudevrules
  --verifyudev


For LVM2:
  devices/obtain_device_list_from_udev=0
  activation/udev_sync=0 (or --noudevsync lvm2 cmd line option)
  activation/udev_rules=0
  activation/verify_udev_operations=1


You can check that udev is bypassed by:

 - checking the /dev/mapper dir - the nodes should be created here instead of symlinks
 - /dev/<vg_name>/<lv_name> should be a symlink to /dev/mapper instead of 
/dev/dm-X
 - also checking the udev database, for example:

   udevadm info --query=all --name=/dev/mapper/vg-lvol0

P: /devices/virtual/block/dm-0
N: dm-0
S: disk/by-id/dm-name-vg-lvol0
S: disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DEVLINKS=/dev/disk/by-id/dm-name-vg-lvol0 /dev/disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DEVNAME=/dev/dm-0
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVTYPE=disk
E: DM_LV_NAME=lvol0
E: DM_NAME=vg-lvol0
E: DM_SUSPENDED=0
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_UUID=LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DM_VG_NAME=vg
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block

So no symlink "S:" record for /dev/mapper/vg-lvol0 and /dev/vg/lvol0. And also there are DM_UDEV_DISABLE_{DM, SUBSYSTEM}_FLAG=1 variables set.


Compared to udev records *without DM_DISABLE_UDEV*:

P: /devices/virtual/block/dm-0
N: dm-0
S: disk/by-id/dm-name-vg-lvol0
S: disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
S: mapper/vg-lvol0
S: vg/lvol0
E: DEVLINKS=/dev/disk/by-id/dm-name-vg-lvol0 /dev/disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ /dev/mapper/vg-lvol0 /dev/vg/lvol0
E: DEVNAME=/dev/dm-0
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVTYPE=disk
E: DM_LV_NAME=lvol0
E: DM_NAME=vg-lvol0
E: DM_SUSPENDED=0
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_UUID=LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DM_VG_NAME=vg
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block

The S:mapper/vg-lvol0 and S:vg/lvol0 is there and DM_UDEV_DISABLE_LIBRARY_FALLBACK=1 is set and no DM_UDEV_DISABLE_*_FLAG set.
Comment 3 Peter Rajnoha 2012-12-04 10:25:36 EST
Also, if you use DM_DISABLE_UDEV=1 and at the same time udevd daemon is running, you should get these warning messages:

$ export DM_DISABLE_UDEV=1
$ lvchange -ay vg
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will manage logical volume symlinks in device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will obtain device list by scanning device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, device-mapper library will manage device nodes in device directory.
Comment 4 Nenad Peric 2012-12-04 10:34:13 EST
Adding QA ACK based on Comment #2
Comment 6 Nenad Peric 2012-12-11 10:18:07 EST
Verified by setting DM_DISABLE_UDEV and by changing the lvm.conf
The behavior is the same, save for the lack of warnings:

  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will manage logical volume symlinks in device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will obtain device list by scanning device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, device-mapper library will manage device nodes in device directory.


Just a note of warning:
Even though it is possible, it is highly _not recommended_ mixing the udev and non-udev devices in a VG. 
This can cause issues later when manipulating those different LVs, especially after deleting the VG which had LVs created in such a combined way (left over orphaned/dangling nodes in /dev and /dev/mapper).
Comment 7 errata-xmlrpc 2013-02-21 03:15:08 EST
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-2013-0501.html

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