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 :)
Hi, the same problem with lvm2-2.02.56-8.xs647 (Xenserver) with 700MB of and 512MB of swap. bye
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).