Bug 740868 - "Internal error: Maps lock 17768448 < unlock 17866752" messages during mirror operations
Summary: "Internal error: Maps lock 17768448 < unlock 17866752" messages during mirror...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 756082
TreeView+ depends on / blocked
 
Reported: 2011-09-23 15:20 UTC by Corey Marthaler
Modified: 2012-03-01 20:33 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-01 20:33:04 UTC


Attachments (Terms of Use)
Simple test for mlock/munlock (2.13 KB, text/plain)
2012-01-04 12:16 UTC, Peter Rajnoha
no flags Details

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?


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