Project

General

Profile

Bug #10821

failed mkfs.btrfs as part of OSD setup

Added by Greg Farnum over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
High
Assignee:
Sandon Van Ness
Category:
-
Target version:
-
Start date:
02/10/2015
Due date:
% Done:

100%

Source:
Q/A
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:

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?

History

#1 Updated by Samuel Just over 4 years ago

  • Project changed from Ceph to teuthology

#3 Updated by Sandon Van Ness over 4 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.

Also available in: Atom PDF