Bug 740868

Summary: "Internal error: Maps lock 17768448 < unlock 17866752" messages during mirror operations
Product: Red Hat Enterprise Linux 6 Reporter: Corey Marthaler <cmarthal>
Component: lvm2Assignee: Zdenek Kabelac <zkabelac>
Status: CLOSED WORKSFORME QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: agk, dwysocha, heinzm, jbrassow, mbroz, prajnoha, prockai, thornber, zkabelac
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-01 20:33:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 756082    
Attachments:
Description Flags
Simple test for mlock/munlock none

Description Corey Marthaler 2011-09-23 15:20:58 UTC 
Description of problem:
I've seen this error on the latest rpms while running splitmirrors test cases. The cases don't actually fail, they just report these errors.


SCENARIO - [attempt_split_using_existing_split_name]
Create a 3-way mirror and attempt to split off from it twice using the same new name
taft-01: lvcreate -m 3 -n split_same_name -L 300M split_image
Waiting until all mirrors become fully syncd...
   0/1 mirror(s) are fully synced: ( 91.17% )
   1/1 mirror(s) are fully synced: ( 100.00% )

first image split...
taft-01: lvconvert --splitmirrors 1 --name new split_image/split_same_name
Although the mirror removal passed, errors were found in it's output
  Logical volume split_same_name converted.
  Internal error: Maps lock 17768448 < unlock 17866752
attempt second image split using same name...

Deactivating mirror new... and removing
Deactivating mirror split_same_name... and removing


SCENARIO - [split_nosync_mirror]
Create a 3-way nosync mirror and split it
taft-01: lvcreate --nosync -m 2 -n split_nosync -L 300M split_image
  WARNING: New mirror won't be synchronised. Don't read what you didn't write!
Waiting until all mirrors become fully syncd...
   1/1 mirror(s) are fully synced: ( 100.00% )

splitting off leg from nosync...
Although the mirror removal passed, errors were found in it's output
  Logical volume split_nosync converted.
  Internal error: Maps lock 17772544 < unlock 17887232



Version-Release number of selected component (if applicable):
2.6.32-198.el6.x86_64

lvm2-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
lvm2-libs-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
lvm2-cluster-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
udev-147-2.38.el6    BUILT: Fri Sep  9 16:25:50 CDT 2011
device-mapper-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
device-mapper-libs-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
device-mapper-event-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
device-mapper-event-libs-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
cmirror-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011


How reproducible:
It's been seen a few times.
Comment 3 Corey Marthaler 2011-10-05 20:10:00 UTC 
Saw this while running mirror deactivates:

[root@taft-01 ~]# vgremove helter_skelter
Do you really want to remove volume group "helter_skelter" containing 1 logical volumes? [y/n]: y
Do you really want to remove active logical volume syncd_pri_leg_pri_log_2legs_2logs_1? [y/n]: y
  Logical volume "syncd_pri_leg_pri_log_2legs_2logs_1" successfully removed
  Volume group "helter_skelter" successfully removed
  Internal error: Maps lock 17981440 < unlock 20078592

[root@taft-01 ~]# uname -ar
Linux taft-01 2.6.32-203.el6.x86_64 #1 SMP Tue Sep 27 11:36:49 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
Comment 5 Peter Rajnoha 2012-01-04 12:14:06 UTC 
I tried to reproduce with a simple program provided by Zdenek (it should reveal the problem in mlock/munlock inconsistency), but it seems to be fine (tried on latest 6.2 kernel 2.6.32-220.2.1.el6.x86_64 as well as the one reported here 2.6.32-198.el6.x86_64). I'm setting cond nak reproducer for now.
Comment 6 Peter Rajnoha 2012-01-04 12:16:02 UTC 
Created attachment 550667 [details]
Simple test for mlock/munlock
Comment 7 Zdenek Kabelac 2012-02-05 15:54:50 UTC 
Is this problem still present - or is it already resolved and could be closed?