Bug 191531

Summary: kernel dm snapshot: ENOMEM after a number of snapshots
Product: [Fedora] Fedora Reporter: Brian J. Murrell <brian>
Component: device-mapper-obsoleteAssignee: Milan Broz <mbroz>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: agk, christophe.varoqui, dmilburn, dwysocha, egoggin, lmb, mbroz, pvrabec, tranlan
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-13 16:10:49 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 Brian J. Murrell 2006-05-12 19:08:57 UTC
Description of problem:


Version-Release number of selected component (if applicable):
device-mapper-1.01.02-1.0


How reproducible:
100%

Steps to Reproduce:
1. Create a pv, vg and finaly an lv, let's call it "test". then
2. for x in $(seq 1 20); do
      lvcreate -s -L1G -n test$x /dev/vg/test || break
   done

On my local system I get an ENOMEM after about 16 snapshots.
  
Expected results:
Many more snapsots, not limited by the maximum size of a single kmalloc.

Additional info:
We have managed to trace the problem to the use of mempools for the _io_pool and
that adding snspshots requires the pool be grown, which ends up hitting the 
limits that kmalloc() imposes on allocations.

Is this a known limitiation?  Are there any plans to solve/eliminate it?  If
somebody were to take on reworking that area of code/design, do you have any
preferences or designs in how it is done?

Comment 2 Milan Broz 2007-06-13 16:10:49 UTC

*** This bug has been marked as a duplicate of 208172 ***