[linux-lvm] Re: bug in CLING allocator on lv extend

[Jun'ichi Nomura]

Hi Jens,

Thanks for testing and detailed bug report.

Attached patch will fix the problem.
I have tested it with your test case and it works well.
Please check on your environment, too.

The cause of the problem was that _alloc_parallel_area()
in lib/metadata/lv_manip.c assumed either:
  - areas in "areas[]" are sorted in size
or
  - all areas in areas[] are large enough to fulfill the
    allocation request at once
So it's been ok just to check the last item of areas[]
for adjusting the allocation size.

Under the "cling" policy, this assumption is no longer true.

BTW, the bug was already fixed in the allocation patch set
posted to lvm-devel on Oct. 13, which is not yet accepted.

Jens Wilke wrote:
> I did some extensive tests of the new CLING allocator algorithm which
> should allow proper mirror extension.
> 
> Testing with CVS HEAD dated 1st december, this is the error I get on 
> lvextend in a specific test configuration:
> lvextend: metadata/pv_map.c:197: consume_pv_area: Assertion `to_go <= pva->count' failed.
> 
> The problem arises in case of an unbalanced amount of free space on the data disks,
> mimages twisted (mimage_1 on PV0), and a hole (or at least two areas, I suppose)
> that needs to be allocated.
> 
> The attached extendtest.sh is the generic code that leads to the error situation 
> (set environment varibales disk[0-2] and vg respectively).
> 
> The attached extendtest.vg is the meta data backup before the lvextend
> with 3 PVs of 128MB each.

-- 
Jun'ichi Nomura, NEC Corporation of America
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-alloc_parallel_area-for-unsorted-areas.patch
Type: text/x-patch
Size: 1241 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20061206/a70d5284/attachment.bin>