Project

General

Profile

Bug #11124

MDSMonitor: refuse to do "fs new" on metadata pools containing objects

Added by Greg Farnum about 2 years ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Category:
Correctness/Safety
Target version:
-
Start date:
03/16/2015
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
Regression:
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Release:
Component(FS):
Needs Doc:
No

Description

#11073 involves a user having old FS objects around after running "fs new" and things going horribly wrong. We need to provide some kind of fencing so that if a user runs "fs new" the old objects are either forcibly removed or no longer used.

I'm partial to tagging all MDS objects with some kind of per-FS identifier (either a UUID, or the mdsmap epoch when the FS was created) that will allow the MDS and monitor to spit out a bunch of warnings. John has also suggested using RADOS namespaces to put the metadata in a different namespace each time. Identify a good plan and implement it.

History

#1 Updated by John Spray about 2 years ago

What about checking pool stats in "fs new" and refusing to operate if either the metadata or data pools already contains >0 objects? If someone genuinely wants to point their new MDSMap at pools with existing objects, they now have "fs reset" for that.

#2 Updated by Sage Weil about 2 years ago

John Spray wrote:

What about checking pool stats in "fs new" and refusing to operate if either the metadata or data pools already contains >0 objects? If someone genuinely wants to point their new MDSMap at pools with existing objects, they now have "fs reset" for that.

this sounds like a nice and simple solution to me

#3 Updated by Greg Farnum 10 months ago

  • Category set to Correctness/Safety

#4 Updated by John Spray 5 months ago

  • Subject changed from MDS: provide some kind of fencing around "fs new" calls to MDSMonitor: refuse to do "fs new" on metadata pools containing objects

#5 Updated by Michal Jarzabek 5 months ago

  • Assignee set to Michal Jarzabek

#6 Updated by Michal Jarzabek 4 months ago

  • Status changed from New to Need Review

#7 Updated by John Spray 4 months ago

  • Status changed from Need Review to Resolved

Also available in: Atom PDF