Bug 112089 - lvm reduce doesn't always update PV free extent count
lvm reduce doesn't always update PV free extent count
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: lvm2 (Show other bugs)
1.0
All Linux
high Severity high
: ---
: ---
Assigned To: Alasdair Kergon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-14 08:05 EST by Alexandre Oliva
Modified: 2005-10-31 17:00 EST (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-12-14 08:05:59 EST
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 15:29:21 EST
Reproduced - any lvresize size reduction with LVM1 metadata is sufficient.
Comment 2 Alasdair Kergon 2004-03-17 15:48:06 EST
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 17:16:11 EST
Patch sent to aoliva to test (ref. bk 1.449)
Comment 4 Alasdair Kergon 2004-03-19 12:03:48 EST
Patch added to public CVS.
Comment 5 Alexandre Oliva 2004-03-21 00:31:46 EST
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 16:55:30 EDT
Fixed in release 2.00.09.
Comment 7 Alexandre Oliva 2004-04-17 15:21:24 EDT
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.