Bug 2142441

Summary:	[RFE] dm-thin: improve performance on CoW-heavy workloads
Product:	[Community] LVM and device-mapper	Reporter:	Demi Marie Obenour <demiobenour>
Component:	device-mapper	Assignee:	LVM Team <lvm-team>
Status:	NEW ---	QA Contact:	cluster-qe <cluster-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, thornber, zkabelac
Target Milestone:	---	Flags:	pm-rhel: lvm-technical-solution?
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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 Demi Marie Obenour 2022-11-14 02:57:20 UTC

dm-thin currently appears to be optimized for overwrite-in-place workloads, where allocation of new blocks is rarer.  In some cases, many or even most writes require allocating new blocks.  This is the case for very short-lived volumes that start out empty, such as volumes used to store container and/or VM images that are being built.  It is also the case in virtualization systems that allow users to roll a VM back to the state before it was started, as this works by creating a snapshot when the VM starts.

Comment 1 Zdenek Kabelac 2022-11-14 11:32:52 UTC

It cannot be said  'dm-thin  is not optimized' - it's the main design principle - which can be summarized with this simple logic:

If you use 'thin volume' - and you takes it's snapshot - blocks are shared with other 'thin volume' from this moment (metadata operation).
Now if you start to 'rewrite' blocks in such volume, since they are now shared, thin volume has to re-provision them - at this moment it does not matter which one from the 2 block 'holders' starts this first - but as long as the thin volume is not an exclusive block owner - the operation of re-provisioning happens.

Note - the operation always happens with the context of running thin volume, so active operation on thin volume A  does not influence anything on thin volume B,C,D...  (except the lock contention with metadata work).

As such it's not very clear how 'different' strategy of thin-provisioning should look like ?

FYI some new patches for thin-pool which improves noticeably performance of thin volumes flows in - so worth to track newest kernels - some of changes might likely have positive influence on your observed problems.


Generic advice:  if there is not much 'sharing' in snapshots overall - increasing the block sizes may significantly reduce performance troubles with metadata handling.