Bug 112089 - lvm reduce doesn't always update PV free extent count
Summary: lvm reduce doesn't always update PV free extent count
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: lvm2   
(Show other bugs)
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-14 13:05 UTC by Alexandre Oliva
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-08 20:57:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

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:

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

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.

Note You need to log in before you can comment on or make changes to this bug.