Bug 889454
| Summary: | LVs are autoactivated when they should not | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Peter Rajnoha <prajnoha> |
| Component: | lvm2 | Assignee: | Peter Rajnoha <prajnoha> |
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.4 | CC: | agk, cmarthal, dwysocha, heinzm, jbrassow, mcsontos, msnitzer, nperic, prajnoha, prockai, thornber, tlavigne, zkabelac |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-21 08:15:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 895654 | ||
|
Description
Peter Rajnoha
2012-12-21 09:28:13 UTC
A fix for relevant udev rules has been pushed upstream: http://git.fedorahosted.org/cgit/lvm2.git/commit/?id=756bcabbfe297688ba240a880bc2b55265ad33f0 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) 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. 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!) 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" ? (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! (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. (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 (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. *** Bug 886695 has been marked as a duplicate of this bug. *** *** Bug 886694 has been marked as a duplicate of this bug. *** 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? (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. 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) 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. 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 |