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 889454 - LVs are autoactivated when they should not
Summary: LVs are autoactivated when they should not
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.4
Hardware: All
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Peter Rajnoha
QA Contact: Cluster QE
URL:
Whiteboard:
: 886694 886695 (view as bug list)
Depends On:
Blocks: 895654
TreeView+ depends on / blocked
 
Reported: 2012-12-21 09:28 UTC by Peter Rajnoha
Modified: 2013-02-21 08:15 UTC (History)
13 users (show)

Fixed In Version: lvm2-2.02.98-7.el6
Doc Type: Bug Fix
Doc Text:
No documentation needed. The autoactivation - pvscan --cache -aay feature is new in 6.4.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:15:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0501 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2013-02-20 21:30:45 UTC

Description Peter Rajnoha 2012-12-21 09:28:13 UTC 
We should limit the way pvscan --cache -aay is called from within 69-dm-lvm-metad.rules for PVs that are activated/added in the system and thus limit the way VG/LVs area autoactivated. Currently, the pvscan --cache -aay is called on each ADD and CHANGE uevent (for a device that is not a device-mapper device) and each CHANGE event (for a PV that is a device-mapper device).

This causes troubles with autoactivation in some cases as CHANGE event may originate from using the OPTION+="watch" udev rule that is defined in 60-persistent-storage.rules and it's used for all block devices (except fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md* devices). For example, the following sequence incorrectly activates the rest of LVs in a VG if one of the LVs in the VG is being removed:

[root@rhel6-a ~]# pvcreate /dev/sda  
  Physical volume "/dev/sda" successfully created

[root@rhel6-a ~]# vgcreate vg /dev/sda
  Volume group "vg" successfully created

[root@rhel6-a ~]# lvcreate -l1 vg
  Logical volume "lvol0" created

[root@rhel6-a ~]# lvcreate -l1 vg
  Logical volume "lvol1" created

[root@rhel6-a ~]# vgchange -an vg
  0 logical volume(s) in volume group "vg" now active

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m                                             
  lvol1   vg        -wi------   4.00m               


[root@rhel6-a ~]# lvremove -ff vg/lvol1
  Logical volume "lvol1" successfully removed

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi-a----   4.00m        


...so the vg was deactivated, then lvol1 removed, and we end up with lvol1 removed (which is ok) BUT with lvol0 activated (which is wrong)!!! This is because after lvol1 removal, we need to write metadata to the underlying device /dev/sda and that causes the CHANGE event to be generated (because of the WATCH udev rule set on this device) and this causes the pvscan --cache -aay to be reevaluated.


We have to limit this and call pvscan --cache -aay to autoactivate VGs/LVs only in these cases:

 --> if the *PV is not a dm device*, scan only after proper device addition (ADD event) and not with any other changes (CHANGE event)

 --> if the *PV is a dm device*, scan only after proper mapping activation (CHANGE event + the underlying PV in a state "just activated")
Comment 1 Peter Rajnoha 2012-12-21 09:41:18 UTC 
A fix for relevant udev rules has been pushed upstream:

http://git.fedorahosted.org/cgit/lvm2.git/commit/?id=756bcabbfe297688ba240a880bc2b55265ad33f0
Comment 2 Marian Csontos 2012-12-21 20:21:08 UTC 
This fixed the issue - test suite is passing[1] again.

[1] Have not got enough time to run all tests, but so far 100% pass (except known and reported issues)
Comment 3 Nenad Peric 2013-01-03 15:00:10 UTC 
Adding QA ack based on the test in the opening comment. 
Testing that LVs unrelated to the operation currently being done (lvremove) should not be auto-activated.
Comment 4 Peter Rajnoha 2013-01-03 15:26:49 UTC 
An alternative and a more general test for the proper autoactivation is also:

For non-dm PVs:
===============
[root@rhel6-a ~]# pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created

[root@rhel6-a ~]# vgcreate vg /dev/sda
  Volume group "vg" successfully created

[root@rhel6-a ~]# lvcreate -l1 vg
  Logical volume "lvol0" created

[root@rhel6-a ~]# vgchange -an vg
  0 logical volume(s) in volume group "vg" now active

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m                                             

[root@rhel6-a ~]# echo change > /sys/block/sda/uevent 

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m                                             

[root@rhel6-a ~]# echo add > /sys/block/sda/uevent 

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi-a----   4.00m                                             

(^^ only ADD uevents have effect for non-dm PVs)

[root@rhel6-a ~]# vgremove -ff vg
  Logical volume "lvol0" successfully removed

For dm PVs:
===========
[root@rhel6-a ~]# dmsetup create test --table "0 262140 linear /dev/sda 4"

[root@rhel6-a ~]# pvcreate /dev/mapper/test
  Physical volume "/dev/mapper/test" successfully created

[root@rhel6-a ~]# vgcreate vg /dev/mapper/test
  Volume group "vg" successfully created

[root@rhel6-a ~]# lvcreate -l1 vg
  Logical volume "lvol0" created

[root@rhel6-a ~]# vgchange -an vg
  0 logical volume(s) in volume group "vg" now active

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m                                             

[root@rhel6-a ~]# dmsetup info -c -o name,blkdevname
Name              BlkDevName      
test              dm-2  

[root@rhel6-a ~]# echo add > /sys/block/dm-2/uevent 

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m                                             

[root@rhel6-a ~]# echo change > /sys/block/dm-2/uevent 

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi------   4.00m                                             

[root@rhel6-a ~]# dmsetup suspend test

[root@rhel6-a ~]# dmsetup resume test

[root@rhel6-a ~]# lvs
  LV      VG        Attr      LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  lvol0   vg        -wi-a----   4.00m                                             

(^^ neither ADD or CHANGE event has effect, it must be a proper DM activation!)
Comment 6 Nenad Peric 2013-01-09 15:27:23 UTC 
Even thouygh the auto-activation does not happen while using LVM command as stated in description, the LV does get activated when it shouldn't by echoing change into uevent:

(09:15:44) [root@r6-node01:~]$ vgcreate vg /dev/sda1
  Volume group "vg" successfully created
(09:16:04) [root@r6-node01:~]$ lvcreate -l2 vg
  Logical volume "lvol0" created

(09:16:18) [root@r6-node01:~]$ vgchange -an vg
  0 logical volume(s) in volume group "vg" now active
(09:16:19) [root@r6-node01:~]$ lvs
  LV      VG       Attr      LSize Pool Origin Data%  Move Log Cpy%Sync Convert
  lv_root VolGroup -wi-ao--- 7.54g                                             
  lv_swap VolGroup -wi-ao--- 1.97g                                             
  lvol0   vg       -wi------ 8.00m                                             
(09:16:21) [root@r6-node01:~]$ echo CHANGE >/sys/block/sda/sda1/uevent 
(09:16:29) [root@r6-node01:~]$ lvs
  LV      VG       Attr      LSize Pool Origin Data%  Move Log Cpy%Sync Convert
  lv_root VolGroup -wi-ao--- 7.54g                                             
  lv_swap VolGroup -wi-ao--- 1.97g                                             
  lvol0   vg       -wi-a---- 8.00m                                      


This does not happen when small "change" is used. 
Does this mean that it would activate on anything passed to uevent other than small "change" ?
Comment 7 Peter Rajnoha 2013-01-09 15:38:01 UTC 
(In reply to comment #6)
> (09:16:21) [root@r6-node01:~]$ echo CHANGE >/sys/block/sda/sda1/uevent 
> (09:16:29) [root@r6-node01:~]$ lvs
>   LV      VG       Attr      LSize Pool Origin Data%  Move Log Cpy%Sync
> Convert
>   lv_root VolGroup -wi-ao--- 7.54g                                          
> 
>   lv_swap VolGroup -wi-ao--- 1.97g                                          
> 
>   lvol0   vg       -wi-a---- 8.00m                                      
> 
> 
> This does not happen when small "change" is used. 
> Does this mean that it would activate on anything passed to uevent other
> than small "change" ?

Hmmm. It should be the other way round! "change" triggers the event and "CHANGE" has no effect (it's ignored). You can check that if you run "udevadm monitor --kernel --env" in parallel. Are you sure it got autoactivated on CHANGE? It must have been something else then!
Comment 8 Peter Rajnoha 2013-01-09 15:43:14 UTC 
(In reply to comment #6)
> (09:16:21) [root@r6-node01:~]$ echo CHANGE >/sys/block/sda/sda1/uevent 

Also, this is a non-dm device, so only "echo add" should have effect on autoactivation, "change", even if used, is ignored in this case with respect to autoactivation.
Comment 9 Nenad Peric 2013-01-09 15:50:32 UTC 
(09:48:49) [root@r6-node01:~]$ lvs
  LV      VG       Attr      LSize Pool Origin Data%  Move Log Cpy%Sync Convert
  lv_root VolGroup -wi-ao--- 7.54g                                             
  lv_swap VolGroup -wi-ao--- 1.97g                                             
  lvol0   vg       -wi------ 4.00m                                             
(09:48:51) [root@r6-node01:~]$ 

echo CHANGE >/sys/block/sda/sda1/uevent 

Monitoring in the other console:

(09:50:13) [root@r6-node01:~]$ udevadm monitor --kernel --env
monitor will print the received events for:
KERNEL - the kernel uevent

KERNEL[1357746634.472216] add      /devices/platform/host9/session8/target9:0:0/9:0:0:1/block/sda/sda1 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/platform/host9/session8/target9:0:0/9:0:0:1/block/sda/sda1
SUBSYSTEM=block
DEVNAME=sda1
DEVTYPE=partition
SEQNUM=7424
MAJOR=8
MINOR=1

KERNEL[1357746634.607162] add      /devices/virtual/bdi/253:2 (bdi)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/virtual/bdi/253:2
SUBSYSTEM=bdi
SEQNUM=7425

KERNEL[1357746634.607534] add      /devices/virtual/block/dm-2 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/virtual/block/dm-2
SUBSYSTEM=block
DEVNAME=dm-2
DEVTYPE=disk
SEQNUM=7426
MAJOR=253
MINOR=2

KERNEL[1357746634.608371] change   /devices/virtual/block/dm-2 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/virtual/block/dm-2
SUBSYSTEM=block
DM_COOKIE=6342711
DEVNAME=dm-2
DEVTYPE=disk
SEQNUM=7427
MAJOR=253
MINOR=2
Comment 10 Peter Rajnoha 2013-01-09 16:00:39 UTC 
(In reply to comment #9)
> echo CHANGE >/sys/block/sda/sda1/uevent 
> 
> KERNEL[1357746634.472216] add     
> /devices/platform/host9/session8/target9:0:0/9:0:0:1/block/sda/sda1 (block)

This is wrong! A kernel bug. The "add" event must not be generated on garbage sent to the /sys/.../uevent.
Comment 11 Peter Rajnoha 2013-01-15 14:47:44 UTC 
*** Bug 886695 has been marked as a duplicate of this bug. ***
Comment 12 Peter Rajnoha 2013-01-15 15:07:38 UTC 
*** Bug 886694 has been marked as a duplicate of this bug. ***
Comment 13 Nenad Peric 2013-01-15 16:39:20 UTC 
What should be done about this BZ, since the kernel BZ I opened (Bug 893922) is not going to be fixed in this release, it has 6.4.0- 

Should we set the kernel one as blocker and see if it can be fixed for the current release?
Comment 14 Marian Csontos 2013-01-16 00:38:07 UTC 
(In reply to comment #13)
> What should be done about this BZ, since the kernel BZ I opened (Bug 893922)
> is not going to be fixed in this release, it has 6.4.0- 

Set to VERIFIED if things are working. We would not be able to close a singe bug if we were waiting for all weakly related bugs.

> 
> Should we set the kernel one as blocker and see if it can be fixed for the
> current release?

I do not see how that could be granted blocker when workaround is as simple as not sending garbage to uevent.
Comment 15 Nenad Peric 2013-01-16 10:07:49 UTC 
Well I understand this, but as stated in Comment #4 that was suggested as a more general test. 

Anyway I am setting this to Verified, tested with opening description commands and a more general set of commands in Comment #4. 

An important note: the test from Comment #4 in the current state of kernel is case-sensitive (change is not the same as CHANGE - the latter causes 'add' to be processed)
Comment 16 Marian Csontos 2013-01-16 10:50:53 UTC 
I reason the upper case was used as a highlighter only and the kernel bug is not related to this issue. Just use `change` and `add` in tests.

Maybe include `ADD`, `CHANGE` and `gIBb3r15h` to verify no unexpected events are generated but that should be tracked by Bug 893922 and not here. At most dependency could be added here.
Comment 17 errata-xmlrpc 2013-02-21 08:15:29 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-2013-0501.html
Note You need to log in before you can comment on or make changes to this bug.