Bug 679780

Summary: pvck: out of memory
Product: [Fedora] Fedora Reporter: Peter Rajnoha <prajnoha>
Component: lvm2Assignee: Peter Rajnoha <prajnoha>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: 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:

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).