Bug 1491609

Summary:	[RFE] Implement forcible volume removal for in-use volumes
Product:	[Community] LVM and device-mapper	Reporter:	Zdenek Kabelac <zkabelac>
Component:	lvm2	Assignee:	LVM Team <lvm-team>
lvm2 sub component:	Command-line tools	QA Contact:	cluster-qe <cluster-qe>
Status:	NEW ---	Docs Contact:
Severity:	unspecified
Priority:	low	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, thornber, zkabelac
Version:	2.02.174	Flags:	rule-engine: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Milestone:	---
Target Release:	---
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:		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 Zdenek Kabelac 2017-09-14 09:19:23 UTC

Description of problem:

While users can use thin-pool with lots of thin LVs - there can be cases, where user may prefer to 'drop' some volumes to make space for other more important ones.  This is fine as long as 'low-prio' thin volumes are not use - but it's getting complicated for the case volumes is in use 'somewhere'.

The possible take on lvm2 side could be - to migrate such LV (no just thin) to a single segmented 'error'  LV -  which den gives  thin-pool change to drop conntent of such thinLV.

Once the 'error' LV gets unused - it can be easily lvremoved  - either later by user or some monitoring process (lvmpolld) - or any later 'lvcreate/lvconvert' my check & drop such LV appropriately flagged.

In practical implementation this is equivalent of using:
'dmsetup remove --force'.

Naive assumptions to be explored is - the reaction of mounted filesystem replaced with error device - in most cases I'd expect the filesystem will not kill the system - just stops itself...  but this needs to be validated...

As for users's API - ideas may range from adding flag option to even extra command...

'lvremove --force --atleastreplacewitherror vg/lv' 
to
'lverror  vg/lv'


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

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Zdenek Kabelac 2018-03-29 13:23:57 UTC

I guess the inital good progress can be achieve with support for:


'lvconvert --type error|zero'

this can may simplify number of recovery operations.


This operation might be even support for VG with missing PV - as it does not present problem for PV allocation - and in practice it five lower-lever control for this case.