Bug 817771

Summary:	[RFE] Investigate options for restructuring internal VG metadata handling to improve scalability
Product:	[Community] LVM and device-mapper	Reporter:	Alasdair Kergon <agk>
Component:	lvm2	Assignee:	LVM and device-mapper development team <lvm-team>
lvm2 sub component:	Metadata	QA Contact:	cluster-qe <cluster-qe>
Status:	CLOSED DEFERRED	Docs Contact:
Severity:	medium
Priority:	unspecified	CC:	agk, dwysocha, heinzm, jbrassow, msnitzer, nkinder, pasik, prajnoha, thornber, zkabelac
Version:	0-beta1	Keywords:	FutureFeature
Target Milestone:	---	Flags:	rule-engine: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-10 21:54:31 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 Alasdair Kergon 2012-05-01 08:25:39 UTC

Currently metadata is atomic at the VG level.

May need ability to update subset of LVs atomically.

May need ability to extend LVs into free space in parallel.

[This bugzilla deals with conceptual metadata changes (internal representation).  A separate bugzilla deals with external formats.]

Comment 2 RHEL Program Management 2012-05-05 04:17:23 UTC

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 3 Petr Rockai 2012-05-20 12:48:37 UTC

More or less, see bug 817770 -- my proposal would be to make the data structures much more opaque, with query and modify interfaces. Implementation of the "transaction" interface would be a responsibility of individual "formats" (where lvm1 and lvm2 formats can share substantial amount of code). However, removal of lvmcache is more or less an unavoidable first step -- the format code calls into lvmcache create dependency loops and non-local side-effects, which make it very hard to expose a semantically coherent format API.

As a side matter, I would seriously entertain the option of implementing (portions) of the internal LVM library in C++ instead of vanilla C. The above-mentioned query/modify interface abstraction would be much simpler and more transparent in C++. Additionally, a lot of LVM code could hugely benefit from automatic resource management (RAII), eliminating entire classes of bugs that exist nowadays. Any externally visible APIs can still be in C without substantial extra effort. Finally, a switch from C to C++ is relatively painless and can be quite gradual.

Comment 4 RHEL Program Management 2012-07-10 08:25:04 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 RHEL Program Management 2012-07-10 23:57:56 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 6 Tom Lavigne 2012-09-07 15:22:21 UTC

This request was evaluated by Red Hat Product Management for 
inclusion in the current release of Red Hat Enterprise Linux.
Since we are unable to provide this feature at this time,  
it has been proposed for the next release of 
Red Hat Enterprise Linux.

Comment 8 Peter Rajnoha 2015-10-14 08:57:02 UTC

This is not a change suitable for RHEL6, moving to RHEl7 for consideration.