Description of problem: Version-Release number of selected component (if applicable): lvm2-2.02.97-1.fc18.x86_64 kernel-3.6.0-3.fc18.x86_64 How reproducible: Steps to Reproduce: # lvcreate -T -V 1G -l1000 -n lv1 vg/pool1 Rounding up size to full physical extent 4.00 MiB device-mapper: remove ioctl on failed: Device or resource busy Logical volume "lv1" created # lvs vg -o+discards LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Discards lv1 vg Vwi-a-tz 1.00g pool1 0.00 ignore pool1 vg twi-a-tz 3.91g 0.00 ignore # lvchange -an vg/pool1 # lvchange --discards=passdown vg/pool1 Logical volume "pool1" changed # lvchange -ay vg/pool1 WARNING: Thin pool target does not support discards (needs kernel >= 3.4). device-mapper: reload ioctl on failed: Invalid argumen # echo $? 5 the debug log: === #metadata/metadata.c:2247 Calculated readahead of LV pool1 is 256 #libdm-deptree.c:2380 Loading vg-pool1_tdata table (253:6) #libdm-deptree.c:2324 Adding target to (253:6): 0 8192000 linear 104:2 384 #ioctl/libdm-iface.c:1687 dm table (253:6) OF [16384] (*1) #libdm-deptree.c:2415 Suppressed vg-pool1_tdata (253:6) identical table reload. #libdm-deptree.c:2380 Loading vg-pool1_tmeta table (253:5) #libdm-deptree.c:2324 Adding target to (253:5): 0 8192 linear 104:2 8192384 #ioctl/libdm-iface.c:1687 dm table (253:5) OF [16384] (*1) #libdm-deptree.c:2415 Suppressed vg-pool1_tmeta (253:5) identical table reload. #libdm-deptree.c:2380 Loading vg-pool1-tpool table (253:7) #libdm-deptree.c:2324 Adding target to (253:7): 0 8192000 thin-pool 253:5 253:6 128 0 0 #ioctl/libdm-iface.c:1687 dm table (253:7) OF [16384] (*1) #ioctl/libdm-iface.c:1687 dm reload (253:7) NF [16384] (*1) #ioctl/libdm-iface.c:1705 device-mapper: reload ioctl on failed: Invalid argument === Actual results: Expected results: Additional info:
Created attachment 624014 [details] lvchange.log
I believe this bug is already fixed upstream in this patch set: https://www.redhat.com/archives/lvm-devel/2012-August/msg00028.html Should be ready for retesting with 2.02.98 release.
lvm2-2.02.98-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/lvm2-2.02.98-1.fc18
Package lvm2-2.02.98-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lvm2-2.02.98-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17684/lvm2-2.02.98-1.fc18 then log in and leave karma (feedback).
Package lvm2-2.02.98-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lvm2-2.02.98-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17684/lvm2-2.02.98-2.fc18 then log in and leave karma (feedback).
(In reply to comment #2) > I believe this bug is already fixed upstream in this patch set: > > https://www.redhat.com/archives/lvm-devel/2012-August/msg00028.html > > Should be ready for retesting with 2.02.98 release. still hit it in lvm2-2.02.98-2.el7.x86_64 [root@el7 tc]# lvs -o+discards vg LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Discards lv1 vg Vwi-a-tz- 100.00m pool1 0.00 passdown pool1 vg twi-a-tz- 400.00m 0.00 passdown [root@el7 tc]# lvchange -an vg/pool1 [root@el7 tc]# lvchange --discards nopassdown vg/pool1 Logical volume "pool1" changed [root@el7 tc]# !lvs lvs -o+discards vg LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Discards lv1 vg Vwi-a-tz- 100.00m pool1 0.00 nopassdown pool1 vg twi---tz- 400.00m 0.00 nopassdown [root@el7 tc]# lvchange -ay vg/pool1 [root@el7 tc]# lvchange -an vg/pool1 [root@el7 tc]# lvchange --discards ignore vg/pool1 Logical volume "pool1" changed [root@el7 tc]# lvchange -ay vg/pool1 device-mapper: reload ioctl on failed: Invalid argument [root@el7 tc]# echo $? 5 attaching the log.
Created attachment 644535 [details] lvchange_lvm2-2.02.98-2.log
this issue existed in both F18 and RHEL7 although the above testing result is for RHEL7
Hmmm is the kernel version being in use for this test. Seems like routine checking for thinp available features doesn't always works as expected. You cannot change live passdown device to ignore. You should be able to do that for offline LV. On next activation it should be detected and approriate target line should be passed to kernel - in the format kernel supports. Thus if you have kernel without supported feature, some previous default should be passed in.
(In reply to comment #9) > Hmmm is the kernel version being in use for this test. > > Seems like routine checking for thinp available features doesn't always > works as expected. > > You cannot change live passdown device to ignore. > You should be able to do that for offline LV. Is it possible if i activate/deactivate the thin pool if will do same thing for the LV based on it? Just like we activate the VG then all the LVs based on VG will be activated. > On next activation it should be detected and approriate target line should > be passed to kernel - in the format kernel supports. Thus if you have kernel > without supported feature, some previous default should be passed in.
(In reply to comment #10) > (In reply to comment #9) > > Hmmm is the kernel version being in use for this test. > > > > Seems like routine checking for thinp available features doesn't always > > works as expected. > > > > You cannot change live passdown device to ignore. > > You should be able to do that for offline LV. > Is it possible if i activate/deactivate the thin pool if will do same thing > for the LV based on it? Just like we activate the VG then all the LVs based > on VG will be activated. Unsure if I get correctly what do you mean here, basically lvchange -an vg/thinpool currently deactivates only 'fake/help/linear' virtual LV for allowing operation on thin pool without having to active any thin volume. (It's there for mainly for clean 'cluster' support and exclusive activation). Thus you could currently deactivate thin pool volume without deactivating any related thin volume. I expect that typical use-case will take whole VG for thin pool and its volumes, thus user may easily deactivate whole VG to take down all LVs.
lvm2-2.02.98-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.