Bug 191531 - kernel dm snapshot: ENOMEM after a number of snapshots
kernel dm snapshot: ENOMEM after a number of snapshots
Status: CLOSED DUPLICATE of bug 208172
Product: Fedora
Classification: Fedora
Component: device-mapper-obsolete (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Milan Broz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-12 15:08 EDT by Brian J. Murrell
Modified: 2013-02-28 23:04 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-13 12:10:49 EDT
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 Brian J. Murrell 2006-05-12 15:08:57 EDT
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 12:10:49 EDT

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

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