Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1592491

Summary: cache pool sub device should not be allowed to be deactivated w/ active origin vol
Product: Red Hat Enterprise Linux 7 Reporter: Corey Marthaler <cmarthal>
Component: lvm2Assignee: LVM and device-mapper development team <lvm-team>
lvm2 sub component: Cache Logical Volumes QA Contact: cluster-qe <cluster-qe>
Status: CLOSED NOTABUG Docs Contact:
Severity: medium    
Priority: unspecified CC: agk, heinzm, jbrassow, msnitzer, prajnoha, zkabelac
Version: 7.6Keywords: Regression
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-22 11:01:44 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:

Description Corey Marthaler 2018-06-18 16:20:49 UTC 
Description of problem:
This is a regression of bug 1108380.

SCENARIO - [create_cache_then_deactivate_pool]                                                                                                                                                                                             
Create cache, then attempt to deactivate pool volume                                                                                                                                                                                       
                                                                                                                                                                                                                                           
*** Cache info for this scenario ***                                                                                                                                                                                                       
*  origin (slow):  /dev/sdh1                                                                                                                                                                                                               
*  pool (fast):    /dev/sdf1
************************************

Adding "slow" and "fast" tags to corresponding pvs
Create origin (slow) volume
lvcreate --wipesignatures y  -L 4G -n corigin cache_sanity @slow

Create cache data and cache metadata (fast) volumes
lvcreate  -L 2G -n cache_then_deactivate_pool cache_sanity @fast
lvcreate  -L 12M -n cache_then_deactivate_pool_meta cache_sanity @fast

Create cache pool volume by combining the cache data and cache metadata (fast) volumes with policy: smq  mode: writeback
lvconvert --yes --type cache-pool --cachepolicy smq --cachemode writeback -c 32 --poolmetadata cache_sanity/cache_then_deactivate_pool_meta cache_sanity/cache_then_deactivate_pool
  WARNING: Converting cache_sanity/cache_then_deactivate_pool and cache_sanity/cache_then_deactivate_pool_meta to cache pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Create cached volume by combining the cache pool (fast) and origin (slow) volumes
lvconvert --yes --type cache --cachemetadataformat 2 --cachepool cache_sanity/cache_then_deactivate_pool cache_sanity/corigin

Attempting to deactivate pool

lvchange -an cache_sanity/cache_then_deactivate_pool
should not have been able to deactivate cache pool (** regression of bug 1108380 **)

[root@host-086 ~]# lvs -a -o +devices
  LV                                 VG            Attr       LSize   Pool                         Origin          Data%  Meta%  Move Log Cpy%Sync Devices
  [cache_then_deactivate_pool]       cache_sanity  Cwi---C---   2.00g                                              0.00   4.52            0.00     cache_then_deactivate_pool_cdata(0)
  [cache_then_deactivate_pool_cdata] cache_sanity  Cwi-ao----   2.00g                                                                              /dev/sdf1(0)
  [cache_then_deactivate_pool_cmeta] cache_sanity  ewi-ao----  12.00m                                                                              /dev/sdf1(512)
  corigin                            cache_sanity  Cwi-a-C---   4.00g [cache_then_deactivate_pool] [corigin_corig] 0.00   4.52            0.00     corigin_corig(0)
  [corigin_corig]                    cache_sanity  owi-aoC---   4.00g                                                                              /dev/sdh1(0)
  [lvol0_pmspare]                    cache_sanity  ewi-------  12.00m                                                                              /dev/sdb1(0)


Version-Release number of selected component (if applicable):
3.10.0-906.el7.x86_64

lvm2-2.02.179-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
lvm2-libs-2.02.179-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
lvm2-cluster-2.02.179-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
lvm2-lockd-2.02.179-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
lvm2-python-boom-0.8.5-6.el7    BUILT: Mon Jun 18 01:16:13 CDT 2018
cmirror-2.02.179-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
device-mapper-1.02.148-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
device-mapper-libs-1.02.148-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
device-mapper-event-1.02.148-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
device-mapper-event-libs-1.02.148-1.el7    BUILT: Mon Jun 18 01:12:41 CDT 2018
device-mapper-persistent-data-0.7.3-3.el7    BUILT: Tue Nov 14 05:07:18 CST 2017


How reproducible:
Everytime
Comment 3 Zdenek Kabelac 2018-06-22 11:01:44 UTC 
Looking at resulting table state - in this case it all seems to work as designed.

cache-pool is lvm2 'fiction' to have a 'component unit' composed from data and metadata LV - which keeps some cache characteristic.

But there is no real cache-pool device.

There is  'cachedLV'  - which reference 3 active LVs ->
the cached origin LV + cache data + cache metadata.

So the reported state of active LVs is correct.

cache-pool is hidden internal object then you normally cannot activate.

When cache-pool is detached from origin - it's activation internally brinks metadata LV for easy access.

If there was ever before cache-pool shown as 'active' volume for cached LV  - it's been a bug (as there is no cache-pool device).