Bug 112089

Summary:	lvm reduce doesn't always update PV free extent count
Product:	[Retired] Red Hat Raw Hide	Reporter:	Alexandre Oliva <aoliva>
Component:	lvm2	Assignee:	Alasdair Kergon <agk>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	1.0	CC:	heinzm, sct
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-04-08 20:57:40 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexandre Oliva 2003-12-14 13:05:59 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031202

Description of problem:
Given an LVM1 set up created before installing kernel 2.6, running
resize2fs to reduce the ext3 filesystem in an LV to 30GiB and then lvm
lvreduce to reduce the LV to that size (regardless of whether -L 30GB
or -l -extent_count is used), it will increase the number of free
extents correspondingly in the volume group free extent count, but not
in the physical extend from which extents were released.  Then, if I
boot into another root filesystem with kernel 2.4 and lvm1, vgscan
fails because the VG is inconsistent.

Booting into kernel 2.6 with lvm2 works, but lvm vgck doesn't fix the
problem, and lvextend will make the free extent count in the PE
negative, failing to fix the problem too.  Oddly, if I then reduce the
LV again, the free extent count is reduced, but then it remains
inconsistent.

I could only restore the system to a working state with lvm
vgcfgrestore -M 1 -f /etc/lvm/archive/*00000.vg

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


How reproducible:
Always

Steps to Reproduce:
1.Take a lvm1/kernel2.4-created VG with two PVs and a set of
filesystems that take all but 1 of the PEs in each PV
2. Boot into kernel 2.6 with lvm2 and reduce the LV that uses the last
few PEs in the second PV


Actual Results:  The PE count in the second PV wasn't reduced accordingly

Expected Results:  It should

Additional info:

Comment 1 Alasdair Kergon 2004-03-17 20:29:21 UTC

Reproduced - any lvresize size reduction with LVM1 metadata is sufficient.

Comment 2 Alasdair Kergon 2004-03-17 20:48:06 UTC

The bug is a failure to adjust area_len when reducing: is this the
same thing that you mentioned today, Heinz, with respect to fsadm
requirements?

Comment 3 Alasdair Kergon 2004-03-17 22:16:11 UTC

Patch sent to aoliva to test (ref. bk 1.449)

Comment 4 Alasdair Kergon 2004-03-19 17:03:48 UTC

Patch added to public CVS.

Comment 5 Alexandre Oliva 2004-03-21 05:31:46 UTC

I've just verified that current CVS does indeed have the problem
fixed.  Sorry that it took so long.  Unfortunately, even though the
patch you sent me applies cleanly in current rawhide, it doesn't
build.  Does it make sense to try to back-port the patch into the
current rawhide version, or should we expect a release containing this
fix to make it to rawhide soon?  Thanks,

Comment 6 Alasdair Kergon 2004-04-08 20:55:30 UTC

Fixed in release 2.00.09.

Comment 7 Alexandre Oliva 2004-04-17 19:21:24 UTC

Verified in lvm2-2.00.14-1.1, thanks.