Bug #11124
closedMDSMonitor: refuse to do "fs new" on metadata pools containing objects
0%
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.
Updated by John Spray about 9 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.
Updated by Sage Weil about 9 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
Updated by John Spray over 7 years 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
Updated by Michal Jarzabek over 7 years ago
- Status changed from New to Fix Under Review
Updated by John Spray about 7 years ago
- Status changed from Fix Under Review to Resolved