MDSMonitor: refuse to do "fs new" on metadata pools containing objects
#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.
#2 Updated by Sage Weil over 4 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