Pending deletions

Because Ozone handles deletion asynchronously, this Pending Deletion widget provides transparency into the multi-stage data deletion pipeline. It tracks how deletion requests flow from the Ozone Manager (OM) down to physical removal on the DataNodes.

The Pending Deletion widget breaks down pending data deletions across three system components:

Ozone Manager (OM): Keys or directories deleted by the client, but whose underlying blocks have not yet been processed by the Storage Container Manager (SCM).
Storage Container Manager: Blocks that SCM has identified as ready for deletion and is actively commanding DataNodes to remove.
DataNodes: Blocks currently queued on individual DataNodes waiting for physical disk deletion.

important

If active database tracking shows a large variance from reported disk usage, or you notice a persistently high Pending Deletion value, it typically points to un-reclaimed deleted block backlogs or delayed asynchronous deletion pipelines.
Example: If SCM shows a large amount of pending deletion (example, 1 TB) but the DataNodes stage shows 0 B, SCM may be failing to communicate deletion commands to the nodes.
Ozone processes deletions asynchronously, which can cause temporary overlaps in pending deletion metrics across distributed components:
- Ozone Manager (OM) to Storage Container Manager (SCM): When OM deletes data (example, 10 GB), it issues a block-deletion request to SCM. During initial processing, both OM and SCM may simultaneously report 10 GB pending deletion. After OM updates its state, OM reports 0 GB while SCM continues to report 10 GB until execution completes.
- SCM to DataNodes: A similar propagation delay occurs while SCM dispatches block-deletion commands to the underlying DataNodes.