RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 969217 - pool create attempt failure: device-mapper: create ioctl on snapper_thinp-POOL_tmeta failed: Device or resource busy
Summary: pool create attempt failure: device-mapper: create ioctl on snapper_thinp-POO...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-30 22:44 UTC by Corey Marthaler
Modified: 2023-03-08 07:25 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-24 12:26:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
pool create attempt (167.12 KB, text/plain)
2013-05-30 22:44 UTC, Corey Marthaler
no flags Details

Description Corey Marthaler 2013-05-30 22:44:49 UTC
Created attachment 755082 [details]
pool create attempt

Description of problem:
After a few iterations of pool test cases, the pool creates eventually start to fail.

[root@qalvm-01 ~]# lvcreate --thinpool POOL -L 1G snapper_thinp
  device-mapper: create ioctl on snapper_thinp-POOL_tmeta failed: Device or resource busy
  Aborting. Failed to activate thin POOL.

[root@qalvm-01 ~]# dmsetup ls
rhel_qalvm--01-swap     (253:0)
rhel_qalvm--01-root     (253:1)
snapper_thinp-POOL-tpool        (253:4)
snapper_thinp-POOL_tdata        (253:3)
snapper_thinp-POOL_tmeta        (253:2)

May 30 17:15:34 qalvm-01 qarshd[3200]: Running cmdline: lvcreate --thinpool POOL -L 1G snapper_thinp
[ 2485.804321] bio: create slab <bio-1> at 1
May 30 17:15:34 qalvm-01 kernel: [ 2485.804321] bio: create slab <bio-1> at 1
[ 2486.138381] bio: create slab <bio-1> at 1
May 30 17:15:34 qalvm-01 kernel: [ 2486.138381] bio: create slab <bio-1> at 1
[ 2486.148750] device-mapper: space map common: index_check failed: blocknr 0 != wanted 25
[ 2486.149742] device-mapper: block manager: index validator check failed for block 25
[ 2486.150695] device-mapper: transaction manager: couldn't open metadata space map
[ 2486.151860] device-mapper: thin metadata: tm_open_with_sm failed
[ 2486.157302] device-mapper: table: 253:4: thin-pool: Error creating metadata object
May 30 17:15:34 [ 2486.158472] device-mapper: ioctl: error adding target to table
qalvm-01 kernel: [ 2486.148750] device-mapper: space map common: index_check failed: blocknr 0 != wanted 25
May 30 17:15:34 qalvm-01 kernel: [ 2486.149742] device-mapper: block manager: index validator check failed for block 25
May 30 17:15:34 qalvm-01 kernel: [ 2486.150695] device-mapper: transaction manager: couldn't open metadata space map
May 30 17:15:34 qalvm-01 kernel: [ 2486.151860] device-mapper: thin metadata: tm_open_with_sm failed
May 30 17:15:34 qalvm-01 kernel: [ 2486.157302] device-mapper: table: 253:4: thin-pool: Error creating metadata object
May 30 17:15:34 qalvm-01 kernel: [ 2486.158472] device-mapper: ioctl: error adding target to table


Version-Release number of selected component (if applicable):
3.8.0-0.40.el7.x86_64
lvm2-2.02.99-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
lvm2-libs-2.02.99-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
lvm2-cluster-2.02.99-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
device-mapper-1.02.78-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
device-mapper-libs-1.02.78-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
device-mapper-event-1.02.78-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
device-mapper-event-libs-1.02.78-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013
cmirror-2.02.99-0.39.el7    BUILT: Wed May 29 08:12:36 CDT 2013


How reproducible:
Every time (eventually)

Comment 1 Corey Marthaler 2013-05-30 22:46:10 UTC
This is with virt storage (like bug 966776), I wonder if these may be related.

Comment 2 Zdenek Kabelac 2013-06-05 09:13:41 UTC
Could you please attach 

'dmsetup table; dmsetup info -c' prior run of failing command.
and related  'dmesg' kernel reporting error for this user-space reported error (device-mapper: create ioctl on snapper_thinp-POOL_tmeta failed: Device or resource busy)

#metadata/metadata.c:2212         Calculated readahead of LV POOL is 256
#libdm-deptree.c:1803     Creating snapper_thinp-POOL_tmeta
#ioctl/libdm-iface.c:1724         dm create snapper_thinp-POOL_tmeta LVM-85SbP6GnSX1ALXmZQgh6guKmVhghnAf1s0bjTt3lVlns71cdQs2AsshGjw7GNtWF NF   [16384] (*1)
#ioctl/libdm-iface.c:1742   device-mapper: create ioctl on snapper_thinp-POOL_tmeta failed: Device or resource busy
#libdm-deptree.c:2493         <backtrace>


From this log I'd have guessed - you've had device with name 'snapper_thinp-POOL_tmeta' already present in the dm table - and you've tried to create LV with this name - but creation failed since device with this name was already there.

Comment 3 Zdenek Kabelac 2013-07-24 12:26:52 UTC
Closing as the end of Comment 2 is most probably valid.

It could be end-result of some previously executed and failed command
which may have written something about "Manual intervention needed".

There are error code paths, where it's not trivial to remove dangling table entries from dm table, so in those case user must manually remove them
via dmsetup remove.

If the test is always using same name, than the name collision may easily happen.


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