Bug 864380 - fail to active the thin pool after change its discards to passdown
fail to active the thin pool after change its discards to passdown
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
18
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Zdenek Kabelac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-09 05:51 EDT by Xiaowei Li
Modified: 2015-01-26 19:10 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:06:32 EST
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)
lvchange.log (62.49 KB, text/plain)
2012-10-09 05:53 EDT, Xiaowei Li
no flags Details
lvchange_lvm2-2.02.98-2.log (52.83 KB, text/plain)
2012-11-13 22:41 EST, Xiaowei Li
no flags Details

  None (edit)
Description Xiaowei Li 2012-10-09 05:51:23 EDT
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:
Comment 1 Xiaowei Li 2012-10-09 05:53:26 EDT
Created attachment 624014 [details]
lvchange.log
Comment 2 Zdenek Kabelac 2012-10-09 08:56:41 EDT
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.
Comment 3 Fedora Update System 2012-11-06 02:34:40 EST
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
Comment 4 Fedora Update System 2012-11-06 13:47:57 EST
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).
Comment 5 Fedora Update System 2012-11-08 22:20:36 EST
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).
Comment 6 Xiaowei Li 2012-11-13 22:28:16 EST
(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.
Comment 7 Xiaowei Li 2012-11-13 22:41:09 EST
Created attachment 644535 [details]
lvchange_lvm2-2.02.98-2.log
Comment 8 Xiaowei Li 2012-11-13 22:42:25 EST
this issue existed in both F18 and RHEL7 although the above testing result is for RHEL7
Comment 9 Zdenek Kabelac 2012-11-14 03:12:45 EST
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.
Comment 10 Xiaowei Li 2012-11-19 01:37:48 EST
(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.
Comment 11 Zdenek Kabelac 2012-11-19 03:39:57 EST
(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.
Comment 12 Fedora Update System 2012-12-20 10:06:36 EST
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.

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