Bug 679780 - pvck: out of memory
pvck: out of memory
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
Unspecified Linux
low Severity medium
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-23 08:57 EST by Peter Rajnoha
Modified: 2012-02-02 04:45 EST (History)
12 users (show)

See Also:
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 04:45:10 EST
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 Peter Rajnoha 2011-02-23 08:57:43 EST
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 16:39:43 EDT
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 09:40:32 EDT
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).

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