Hide Forgot
+++ This bug was initially created as a clone of Bug #1132512 +++ First I created the physical volume, the volume group, one thin pool that almost used all the space of the volume group. Then I created and formated one thinly provisioned volume within this volume group. About a week later my PC had a power failure and was not shutdown cleanly. About two weeks later I opened the luks container and created a new thin volume. I tried to activate it, but I got the following error message. Thin pool transaction_id=5, while expected: 6. So the creation of the volume was successful, but the activation wasn't. I had to activate it manually because the name of the volume group was not listed in the "activation" "volume_list" in lvm.conf during the creation of the volume. The volume group only has one physical volume on a luks encrypted hard drive. The hard drive does not have any partitions. It is a Seagate Barracuda 7200.14 (AF). smartctl does not show any signs of a failure of the hard drive. Kernel: 3.14.14 LVM version: 2.02.108(2) (2014-07-23) Library version: 1.02.87 (2014-07-23) Driver version: 4.27.0 --- Additional comment from Zdenek Kabelac on 2014-08-21 10:03:23 EDT --- Yep tricky one - we miss to really pass messages to thin pools which happens to be skipped because of volume_list. This bug may easily lead to desynchronization of kernel and lvm2 metadata which requires non-trival effort to fix it.
(In reply to Zdenek Kabelac from comment #0) > Yep tricky one - we miss to really pass messages to thin pools which > happens to be skipped because of volume_list. > > This bug may easily lead to desynchronization of kernel and lvm2 metadata > which requires non-trival effort to fix it. Requesting blocker for this one.
Trying to initially address this bug with upstream commit: https://www.redhat.com/archives/lvm-devel/2014-August/msg00075.html
A simple reproducer could like this - create thin pool deactivate thin pool set volume_list to not allow activation of thin-pool (i.e. put in name of non-existing vg) then try to create thin volume - in buggy version - transaction_id is moved forward but the kernel target doesn't know about it. then when volume_list is set in way to allow activation of thinpool - mistmatching transaction is found and activation of thin pool is not possible and requires fix of lvm2 metadata. With fixed version it should not be possible.
The creation of the thin LV is prevented when thin pool is no longer active (and cannot be due to unmatched volume_list). [root@virt-147 ~]# lvchange -an vg/thin_pool [root@virt-147 ~]# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert [lvol0_pmspare] vg ewi------- 4.00m thin_pool vg twi---tz-- 1.00g [thin_pool_tdata] vg Twi------- 1.00g [thin_pool_tmeta] vg ewi------- 4.00m lv_root vg_virt147 -wi-ao---- 6.71g lv_swap vg_virt147 -wi-ao---- 816.00m [root@virt-147 ~]# lvcreate -T -V1G -n data_LV vg/thin_pool Cannot activate thin pool vg/thin_pool, perhaps skipped in lvm.conf volume_list? [root@virt-147 ~]# lvs -a LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert [lvol0_pmspare] vg ewi------- 4.00m thin_pool vg twi---tz-- 1.00g [thin_pool_tdata] vg Twi------- 1.00g [thin_pool_tmeta] vg ewi------- 4.00m lv_root vg_virt147 -wi-ao---- 6.71g lv_swap vg_virt147 -wi-ao---- 816.00m Marking this VERIFIED with: lvm2-2.02.111-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 lvm2-libs-2.02.111-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 lvm2-cluster-2.02.111-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 udev-147-2.57.el6 BUILT: Thu Jul 24 15:48:47 CEST 2014 device-mapper-1.02.90-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 device-mapper-libs-1.02.90-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 device-mapper-event-1.02.90-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 device-mapper-event-libs-1.02.90-2.el6 BUILT: Mon Sep 1 13:46:43 CEST 2014 device-mapper-persistent-data-0.3.2-1.el6 BUILT: Fri Apr 4 15:43:06 CEST 2014
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-2014-1387.html