Bug 1681968

Summary:	Thin-pool using ~16GB of metadata uses different limit for lvm2 and thin tools
Product:	Red Hat Enterprise Linux 8	Reporter:	Nathaniel Weddle <nweddle>
Component:	lvm2	Assignee:	Zdenek Kabelac <zkabelac>
lvm2 sub component:	Thin Provisioning	QA Contact:	cluster-qe <cluster-qe>
Status:	CLOSED DUPLICATE	Docs Contact:
Severity:	medium
Priority:	medium	CC:	agk, apanagio, heinzm, jbrassow, msnitzer, pasik, prajnoha, thornber, zkabelac
Version:	8.0	Flags:	pm-rhel: mirror+
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-02-01 07:37:06 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 Nathaniel Weddle 2019-02-25 17:26:41 UTC

Description of problem:

When using lvm2 with 16GB (max size) of thin-pool metadata, several operations are not combining well together.

It is allowed to create bigger metadata LV then the size accepted by kernel which does require to not pass bigger device - otherwise messages are thrown back to user from kernel.

Problem could be easily seen when user is passing 16GB LV to thin_restore and then using this 'restored' LV  via lvconvert as a thin-pool metadata LV.


Version-Release number of selected component (if applicable):
2.03.02

How reproducible:
100%

Steps to Reproduce:
1. create thin pool with tmeta of 16GB
2. lvextend -L +30G /dev/mapper/vg-lv--pool_tmeta
3. 

Actual results:
lvs output showing tmeta size change (because it is written into metadata), but dmsetup reports 16GB


Expected results:

lvextend command should probably fail, or at the very least, not write larger tmeta size to metadata.

Additional info:

Comment 2 Alexandros Panagiotou 2020-11-25 17:27:03 UTC

Hello,
I have noticed this accidentally and it seems very similar to the discussion in BZ 1899798.

Kind Regards,
Alexandros

Comment 4 RHEL Program Management 2021-02-01 07:37:06 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 5 Zdenek Kabelac 2021-02-01 15:13:28 UTC


*** This bug has been marked as a duplicate of bug 1909699 ***