| Summary: | Thin pool incorrectly updates transaction_id when it is skipped via volume_list | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Zdenek Kabelac <zkabelac> |
| Component: | lvm2 | Assignee: | Zdenek Kabelac <zkabelac> |
| lvm2 sub component: | Thin Provisioning (RHEL6) | QA Contact: | Cluster QE <mspqa-list> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | medium | ||
| Priority: | unspecified | CC: | agk, bjs, bmarzins, bmr, cmarthal, dwysocha, extras-qa, heinzm, jbrassow, jonathan, lvm-team, msnitzer, nperic, prajnoha, prockai, thornber, tlavigne, zkabelac |
| Version: | 6.6 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.110-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
LVM no longer incorrectly assumes messages were sent to the kernel's thin pool driver when such interaction was forbidden due to a configuration parameter such as activation/volume_list. This could lead to future activation failures reporting a transaction ID mismatch.
|
Story Points: | --- |
| Clone Of: | 1132512 | Environment: | |
| Last Closed: | 2014-10-14 08:25:57 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: | |
| Bug Depends On: | 1132512 | ||
| Bug Blocks: | |||
|
Description
Zdenek Kabelac
2014-08-21 14:23:05 UTC
(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 |