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 1802683 - should writecache volumes be allowed to be used as thin pool meta volumes if they're not allowed to be used for thin pool data volumes?
Summary: should writecache volumes be allowed to be used as thin pool meta volumes if ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.2
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: 8.0
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-13 17:28 UTC by Corey Marthaler
Modified: 2021-09-07 11:54 UTC (History)
9 users (show)

Fixed In Version: lvm2-2.03.08-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:59:23 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-37283 0 None None None 2021-09-07 11:54:20 UTC
Red Hat Product Errata RHEA-2020:1881 0 None None None 2020-04-28 16:59:37 UTC

Description Corey Marthaler 2020-02-13 17:28:22 UTC 
Description of problem:
SCENARIO - [attempt_to_create_pool_from_already_writecached_vol]
Attempt to stack a writecache pool on top of a cache volume

*** Writecache info for this scenario ***
*  origin (slow):  /dev/sdg1
*  pool (fast):    /dev/sdh1
************************************

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

Create cache data and cache metadata (fast) volumes
lvcreate  -L 2G -n pool writecache_sanity @fast

Deactivte both fast and slow volumes before conversion to writecache
Create writecached volume by combining the cache pool (fast) and origin (slow) volumes
lvconvert --yes --type writecache --cachesettings ' low_watermark=49 high_watermark=77 writeback_jobs=1938 autocommit_blocks=2896 autocommit_time=2784' --cachevol writecache_sanity/pool writecache_sanity/stack1
Activating volume: stack1

lvcreate  -L 8M -n meta2 writecache_sanity /dev/sdh1

Attempt to create a new cache pool volume by combining an existing writecached volume and the new metadata volume
lvconvert --yes --type cache-pool --poolmetadata writecache_sanity/meta2 writecache_sanity/stack1
  Command on LV writecache_sanity/stack1 does not accept LV type writecache.
  Command not permitted on LV writecache_sanity/stack1.

# This *would* work if using dm-cache
Attempt to create a new thin pool volume by combining the existing writecached volume and the new metadata volume
lvconvert --yes --type thin-pool --poolmetadata writecache_sanity/meta2 writecache_sanity/stack1
  Command on LV writecache_sanity/stack1 does not accept LV type writecache.
  Command not permitted on LV writecache_sanity/stack1.

# If the above isn't supported, should writecache vols be allowed to be used as meta data devices then either?
Attempt to create a new thin pool volume by combining the existing writecached volume (as the meta device) and the new linear (named meta)
[root@hayes-02 ~]# lvconvert --yes --type thin-pool --poolmetadata writecache_sanity/stack1 writecache_sanity/meta2
  Thin pool volume with chunk size 64.00 KiB can address at most 15.81 TiB of data.
  WARNING: Converting writecache_sanity/meta2 and writecache_sanity/stack1 to thin pool's data and metadata volumes with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
  Converted writecache_sanity/meta2 and writecache_sanity/stack1 to thin pool.
[root@hayes-02 ~]# lvs -a -o +devices
  LV                   VG                Attr       LSize Pool        Origin               Data%  Meta% Cpy%Sync Convert Devices              
  [lvol0_pmspare]      writecache_sanity ewi------- 4.00g                                                                /dev/sdb1(0)         
  meta2                writecache_sanity twi-a-tz-- 8.00m                                  0.00   0.40                   meta2_tdata(0)       
  [meta2_tdata]        writecache_sanity Twi-ao---- 8.00m                                                                /dev/sdh1(512)       
  [meta2_tmeta]        writecache_sanity ewi-aoC--- 4.00g [pool_cvol] [meta2_tmeta_wcorig] 0.01                          meta2_tmeta_wcorig(0)
  [meta2_tmeta_wcorig] writecache_sanity owi-aoC--- 4.00g                                                                /dev/sdg1(0)         
  [pool_cvol]          writecache_sanity Cwi-aoC--- 2.00g                                                                /dev/sdh1(0)         


Version-Release number of selected component (if applicable):
kernel-4.18.0-173.el8    BUILT: Fri Jan 24 06:02:03 CST 2020
lvm2-2.03.08-1.el8    BUILT: Tue Feb 11 07:40:33 CST 2020
lvm2-libs-2.03.08-1.el8    BUILT: Tue Feb 11 07:40:33 CST 2020
device-mapper-1.02.169-1.el8    BUILT: Tue Feb 11 07:40:33 CST 2020
device-mapper-libs-1.02.169-1.el8    BUILT: Tue Feb 11 07:40:33 CST 2020
device-mapper-event-1.02.169-1.el8    BUILT: Tue Feb 11 07:40:33 CST 2020
device-mapper-event-libs-1.02.169-1.el8    BUILT: Tue Feb 11 07:40:33 CST 2020
Comment 1 Corey Marthaler 2020-02-13 22:56:19 UTC 
Looks like the fact that this works is a fluke and needs to be restricted since the uncache and removal doesn't work.

[root@hayes-02 ~]# lvconvert --uncache writecache_sanity/stack1

[root@hayes-02 ~]# lvs -a -o +devices
  LV                   VG                Attr       LSize Pool        Origin               Data%  Meta%  Move Log Cpy%Sync Convert Devices
  [lvol0_pmspare]      writecache_sanity ewi------- 4.00g                                                                          /dev/sdb1(0)     
  meta2                writecache_sanity twi-a-tz-- 8.00m                                  0.00   0.40                             meta2_tdata(0)
  [meta2_tdata]        writecache_sanity Twi-ao---- 8.00m                                                                          /dev/sdc1(512)
  [meta2_tmeta]        writecache_sanity ewi-aoC--- 4.00g [pool_cvol] [meta2_tmeta_wcorig] 0.01                                    meta2_tmeta_wcorig(0)
  [meta2_tmeta_wcorig] writecache_sanity owi-aoC--- 4.00g                                                                          /dev/sdf1(0)
  [pool_cvol]          writecache_sanity Cwi-aoC--- 2.00g                                                                          /dev/sdc1(0)

[root@hayes-02 ~]# lvremove -f writecache_sanity
  LV segment meta2_tmeta:0-4294967295 is incorrectly listed as being used by LV pool_cvol
  Internal error: LV segments corrupted in pool_cvol.
Comment 2 David Teigland 2020-02-13 23:27:00 UTC 
fix in master:
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=db1d66859f8086467979b2d7e32843f70e4436e1

(When swapping, the thin code uses a whitelist of acceptable metadata LV types, but in this lvconvert case it uses a blacklist of unacceptable metadata LV types which is prone to breaking when new LV types are introduced.)
Comment 3 Marian Csontos 2020-02-24 16:21:11 UTC 
Corey, could you ack please?
Comment 6 Corey Marthaler 2020-02-24 21:33:47 UTC 
Fix verified in the latest rpms.

kernel-4.18.0-179.el8    BUILT: Fri Feb 14 17:03:01 CST 2020
lvm2-2.03.08-2.el8    BUILT: Mon Feb 24 11:21:38 CST 2020
lvm2-libs-2.03.08-2.el8    BUILT: Mon Feb 24 11:21:38 CST 2020
device-mapper-1.02.169-2.el8    BUILT: Mon Feb 24 11:21:38 CST 2020
device-mapper-libs-1.02.169-2.el8    BUILT: Mon Feb 24 11:21:38 CST 2020
device-mapper-event-1.02.169-2.el8    BUILT: Mon Feb 24 11:21:38 CST 2020
device-mapper-event-libs-1.02.169-2.el8    BUILT: Mon Feb 24 11:21:38 CST 2020



[root@hayes-02 ~]# lvs -a -o +devices
  LV              VG                Attr       LSize Pool        Origin          Data%  Meta%  Move Log Cpy%Sync Convert Devices         
  meta2           writecache_sanity -wi-a----- 8.00m                                                                     /dev/sdh1(0)    
  [pool_cvol]     writecache_sanity Cwi-aoC--- 2.00g                                                                     /dev/sdm1(0)    
  stack1          writecache_sanity Cwi-a-C--- 4.00g [pool_cvol] [stack1_wcorig] 0.00                                    stack1_wcorig(0)
  [stack1_wcorig] writecache_sanity owi-aoC--- 4.00g                                                                     /dev/sde1(0)    
[root@hayes-02 ~]# lvconvert --yes --type cache-pool --poolmetadata writecache_sanity/meta2 writecache_sanity/stack1
  Command on LV writecache_sanity/stack1 does not accept LV type writecache.
  Command not permitted on LV writecache_sanity/stack1.
[root@hayes-02 ~]# lvconvert --yes --type thin-pool --poolmetadata writecache_sanity/meta2 writecache_sanity/stack1
  Command on LV writecache_sanity/stack1 does not accept LV type writecache.
  Command not permitted on LV writecache_sanity/stack1.
[root@hayes-02 ~]# lvconvert --yes --type thin-pool --poolmetadata writecache_sanity/stack1 writecache_sanity/meta2
  Pool metadata LV writecache_sanity/stack1 is of an unsupported type.
Comment 8 errata-xmlrpc 2020-04-28 16:59:23 UTC 
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.

https://access.redhat.com/errata/RHEA-2020:1881
Note You need to log in before you can comment on or make changes to this bug.