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.
DescriptionJonathan Earl Brassow
2014-06-10 01:18:09 UTC
The following commit has made it impossible to remove a cachepool separately from a cache LV (which should result in a conversion of the origin back to a non-cached LV).
8a60cbcf45c553dfc168552cf9af3059359ec95d is the first bad commit
commit 8a60cbcf45c553dfc168552cf9af3059359ec95d
Date: Tue Mar 11 23:07:41 2014 +0100
thin: always activate and deactive pool when creating
When we create thin-pool we have used trick to keep
volume active, but since we now support TEMPORARY flag,
we could just localy active & deactive metadata LV,
and let the thinpool through normal activation process.
The problem only seems to happen if I create an origin LV first and then the cache-pool LV, like this:
# lvcreate -L 10G -n lv vg
# lvcreate --type cache -L 1G -n lv_cachepool vg/lv
# lvremove -ff vg/lv_cachepool
Before the above commit, the results looked like this:
# lvcreate -L 10G -n lv vg
Logical volume "lv" created
# lvcreate --type cache -L 1G -n lv_cachepool vg/lv
Logical volume "lvol0" created
Logical volume "lv" created
# lvremove -ff vg/lv_cachepool
Flushing cache for lv
6 blocks must still be flushed.
0 blocks must still be flushed.
Logical volume "lv_cachepool" successfully removed
After, it looks like this:
# lvcreate -L 10G -n lv vg
Logical volume "lv" created
# lvcreate --type cache -L 1G -n lv_cachepool vg/lv
Logical volume "lvol0" created
Logical volume "lv" created
# lvremove -ff vg/lv_cachepool
Command failed with status code 5.
I think part of the reason this wasn't caught sooner was because of this commit, which took out the test that creates cache LVs in this way followed by the remove of the cache-pool first:
commit c95d43b28c5f89e1d96f2b16805ecd74eb4b02fb
Date: Tue Apr 1 17:52:29 2014 +0200
tests: update lvcreate-cache
Comment 1Jonathan Earl Brassow
2014-08-27 12:42:35 UTC
not a blocker candidate due to tech preview status
Comment 2Jonathan Earl Brassow
2014-09-25 13:55:01 UTC
still fails exactly as described with upstream code 9/25/2014
The following commit has made it impossible to remove a cachepool separately from a cache LV (which should result in a conversion of the origin back to a non-cached LV). 8a60cbcf45c553dfc168552cf9af3059359ec95d is the first bad commit commit 8a60cbcf45c553dfc168552cf9af3059359ec95d Date: Tue Mar 11 23:07:41 2014 +0100 thin: always activate and deactive pool when creating When we create thin-pool we have used trick to keep volume active, but since we now support TEMPORARY flag, we could just localy active & deactive metadata LV, and let the thinpool through normal activation process. The problem only seems to happen if I create an origin LV first and then the cache-pool LV, like this: # lvcreate -L 10G -n lv vg # lvcreate --type cache -L 1G -n lv_cachepool vg/lv # lvremove -ff vg/lv_cachepool Before the above commit, the results looked like this: # lvcreate -L 10G -n lv vg Logical volume "lv" created # lvcreate --type cache -L 1G -n lv_cachepool vg/lv Logical volume "lvol0" created Logical volume "lv" created # lvremove -ff vg/lv_cachepool Flushing cache for lv 6 blocks must still be flushed. 0 blocks must still be flushed. Logical volume "lv_cachepool" successfully removed After, it looks like this: # lvcreate -L 10G -n lv vg Logical volume "lv" created # lvcreate --type cache -L 1G -n lv_cachepool vg/lv Logical volume "lvol0" created Logical volume "lv" created # lvremove -ff vg/lv_cachepool Command failed with status code 5. I think part of the reason this wasn't caught sooner was because of this commit, which took out the test that creates cache LVs in this way followed by the remove of the cache-pool first: commit c95d43b28c5f89e1d96f2b16805ecd74eb4b02fb Date: Tue Apr 1 17:52:29 2014 +0200 tests: update lvcreate-cache