On Thu, Aug 1, 2019 at 10:48 PM Gregory Farnum <gfarnum(a)redhat.com> wrote:
On Thu, Aug 1, 2019 at 12:06 PM Eric Ivancich <ivancich(a)redhat.com> wrote:
I expect RGW could do this, but unfortunately deleting namespaces at
the RADOS level is not practical. People keep asking and maybe in some
future world it will be cheaper, but a namespace is effectively just
part of the object name (and I don't think it's even the first thing
they sort by for the key entries in metadata tracking!), so deleting a
namespace would be equivalent to deleting a snapshot[1] but with the
extra cost that namespaces can be created arbitrarily on every write
operation (so our solutions for handling snapshots without it being
ludicrously expensive wouldn't apply). Deleting a namespace from the
OSD-side using map updates would require the OSD to iterate through
just about all the objects they have and examine them for deletion.
yes, i was thinking of something similar to snapshot deletion. I assumed
that objects were ordered by namespace internally/that listing a name-space
would be efficient.
Is it cheaper than doing over the network? Sure. Is it cheap enough
we're willing to let a single user request generate that kind of
cluster IO on an unconstrained interface? Absolutely not.
Agreed, nothing wrong with doing it over the network in this case.
Paul
> -Greg
> [1]: Deleting snapshots is only feasible because every OSD maintains a
> sorted secondary index from snapid->set<objects>. This is only
> possible because snapids are issued by the monitors and clients
> cooperate in making sure they can't get reused after being deleted.
> Namespaces are generated by clients and there are no constraints on
> their use, reuse, or relationship to each other. We could maybe work
> around these problems, but it'd be building a fundamentally different
> interface than what namespaces currently are.