Project

General

Profile

Actions
Copy link

Bug #10821

closed

failed mkfs.btrfs as part of OSD setup

Added by Greg Farnum about 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
High
Assignee:
Sandon Van Ness
Category:
-
% Done:

100%

Source:
Q/A
Tags:
Backport:
Regression:
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Crash signature (v1):
Crash signature (v2):

Description

http://pulpito.ceph.com/teuthology-2015-02-08_23:04:01-fs-hammer-testing-basic-multi/745187/
http://pulpito.ceph.com/teuthology-2015-02-08_23:04:01-fs-hammer-testing-basic-multi/745170/
http://pulpito.ceph.com/teuthology-2015-02-08_23:04:01-fs-hammer-testing-basic-multi/745172/

2015-02-09T06:57:55.692 INFO:tasks.ceph:['mkfs.btrfs', '-m', 'single', '-l', '32768', '-n', '32768'] on /dev/sdh on ubuntu@mira114.front.sepia.ceph.com
2015-02-09T06:57:55.693 INFO:teuthology.orchestra.run.mira114:Running: 'yes | sudo mkfs.btrfs -m single -l 32768 -n 32768 /dev/sdh'
2015-02-09T06:57:55.812 INFO:teuthology.orchestra.run.mira114.stderr:/dev/sdh appears to contain an existing filesystem (ddf_raid_member).
2015-02-09T06:57:55.812 INFO:teuthology.orchestra.run.mira114.stderr:Error: Use the -f option to force overwrite.
2015-02-09T06:57:55.815 INFO:tasks.ceph:['mkfs.btrfs', '-m', 'single', '-l', '32768', '-n', '32768', '-f'] on /dev/sdh on ubuntu@mira114.front.sepia.ceph.com
2015-02-09T06:57:55.816 INFO:teuthology.orchestra.run.mira114:Running: 'yes | sudo mkfs.btrfs -m single -l 32768 -n 32768 -f /dev/sdh'
2015-02-09T06:57:55.850 INFO:teuthology.orchestra.run.mira114.stderr:Error: unable to open /dev/sdh: Device or resource busy

The second and third of those are on the same box, so this could just be a hardware issue that needs to get moved into the sepia project. But the first is a different machine and this bug looks new to me. Or maybe the machines are being double locked?

Actions
Copy link
 #1

Updated by Samuel Just about 9 years ago

  • Project changed from Ceph to teuthology
Actions
Copy link
 #3

Updated by Sandon Van Ness about 9 years ago

  • Status changed from New to Resolved
  • Assignee set to Sandon Van Ness
  • % Done changed from 0 to 100

This took some investigation but the cause was kind of an unexpected one. The device mapper was utilizing the devices causing them to busy due to old existing LSI raid controller raid metadata that was left on the disks as the disks were some saved from e-waste disks from DreamHost.

Zeroing out the last 100 megabytes of the disk and rebooting the machine fixed the issue as there was no way to get dmraid to delete the raid metadata.

Actions
Copy link

Also available in: Atom PDF