Bug 679780

Summary:	pvck: out of memory
Product:	[Fedora] Fedora	Reporter:	Peter Rajnoha <prajnoha>
Component:	lvm2	Assignee:	Peter Rajnoha <prajnoha>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	agk, bmarzins, bmr, dwysocha, heinzm, jonathan, listas.vhs, lvm-team, mbroz, msnitzer, prajnoha, prockai
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	lvm2-2.02.89-2.fc17	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-02 09:45:10 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 Peter Rajnoha 2011-02-23 13:57:43 UTC

Description of problem:
I hit this by chance when testing pvcreate --metadatasize.


Version-Release number of selected component (if applicable):
2.02.84 (just a note that this is not related to any .85 changes in metadata handling)

How reproducible:
For example, creating a new PV with metadata area size that is more than the disk size used (automatic metadata size truncation is triggered internally and the mda covers the whole PV then).


Steps to Reproduce:
1. pvcreate --metadatasize 200m /dev/vdc  (vdc is 128m)
2. pvck -v /dev/vdc
  
Actual results:
Found label on /dev/vdc, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=132116480
Killed

/var/log/messages:
Feb 23 14:42:23 localhost kernel: [18642.986981] Out of memory: Kill process 25857 (pvck) score 882 or sacrifice child
Feb 23 14:42:23 localhost kernel: [18642.989634] Killed process 25857 (pvck) total-vm:1530340kB, anon-rss:915548kB, file-rss:4kB

Expected results:
pvck not killed with out of memory, if possible :)

Comment 1 Victor Hugo dos Santos 2011-03-16 20:39:43 UTC

Hi,

the same problem with lvm2-2.02.56-8.xs647 (Xenserver)
with 700MB of and 512MB of swap.

bye

Comment 2 Peter Rajnoha 2011-08-29 13:40:32 UTC

This is caused by using a mempool and trying to allocate more and more memory for the buffer to store part of the metadata area to scan (which increases iteratively). It's more convenient to allocate the memory directly here.

We don't actually need to create the metadata area that is larger than the PV itself as I mentioned earlier in comment #0. I can reproduce even with 2MB metadata area size now.

The patch is in upstream now (v2.02.89).